Transformer condition monitoring software should help an engineer explain why an asset needs attention, what evidence supports that view, and what to do next. A fleet dashboard is useful only when that chain survives inspection.
The buying mistake is to compare screen layouts before testing the decisions behind them. Two products can display the same red transformer while using different inputs, assumptions and definitions of risk. One may preserve a laboratory qualifier; another may silently replace it with zero.
Use representative records to expose these differences before shortlisting suppliers. Share only data approved for the evaluation; synthetic or de-identified records can preserve the test cases without exposing sensitive asset information. The following checks are proposed procurement tests, not standard requirements.
1. Define the Decision You Are Buying
Write down the decision the software must support: selecting records for engineering review, preparing condition reports, coordinating additional tests, or comparing assets for maintenance planning. Specify who approves that decision and how quickly the evidence must be available.
Separate laboratory assessment from online monitoring. The former works with discrete observations and their sampling dates. The latter also introduces sensor availability, time alignment and communications. Our transformer condition monitoring resources provide the broader context; your tender should describe the actual workflow.
For an online demonstration, interrupt the test feed and then restore it. Check whether the display identifies stale values, preserves the last observation time and distinguishes communication loss from a physical asset alarm. Run this in an agreed test environment, not by disconnecting a live operational monitor.
IEEE C57.143-2024 covers application of monitoring equipment and systems, including risk/benefit considerations. Its published scope excludes interpretation of monitoring results. This distinction matters: citing a monitoring guide does not establish that a supplier's diagnostic model is valid.
Ask for a list of supported asset and liquid types. Treat mineral-oil, ester-filled and dry-type equipment as explicit scope decisions. A successful mineral-oil demonstration does not establish ester suitability.
2. Ask for Evidence, Not Feature Checkboxes
Make the supplier demonstrate the following with records you select. The suggested acceptance evidence below is a buyer's requirement, not a claim about any particular product.
| Evaluation area | Ask the supplier to demonstrate | Evidence worth keeping |
|---|---|---|
| Asset identity | Distinguish two units with the same site nickname | Approved identity mapping and unresolved matches |
| Laboratory import | Preserve units, qualifiers and sample dates | Source row beside the imported observation |
| Missing evidence | Process a missing gas and a result below detection | Separate states, visible assessment limitations |
| Assessment method | Explain a changed result after a method update | Method version and before/after comparison |
| Human review | Record a disagreement without losing the original output | Reviewer, rationale and revision history |
| Exit | Export an assessment with its supporting evidence | Readable data, metadata and report files |
For health indices, request the scale direction, component contributions and missing-data policy. A health index is not automatically a calibrated probability of failure. Use the health index introduction to align terminology before comparing supplier scores.
The W3C PROV overview describes provenance through entities, activities and responsible actors. This non-normative overview provides useful vocabulary for tracing an assessment; buying transformer software does not require a particular PROV implementation.
Also ask what happens when a measurement is corrected after a report has been issued. An overwritten chart may look cleaner, but it cannot explain why last month's maintenance meeting reached a different conclusion. Require a demonstration of both the corrected view and the historical record used at that meeting.
3. Run a Small, Adversarial Demonstration
Consider a hypothetical utility evaluating two suppliers using twelve laboratory records. Eight records are straightforward. Four contain deliberate challenges: a duplicate sample, an ambiguous asset name, an ester identifier, and acetylene reported below a laboratory detection limit.
The utility supplies the source reports and an engineer-prepared answer sheet for this synthetic dataset. Supplier A imports every record without questions. Supplier B requests identity confirmation, flags the duplicate, and explains that the ester record is outside the demonstrated method scope. It also retains the acetylene result's qualifier and detection limit instead of treating the result as measured zero.
Supplier B has not necessarily won: unresolved records, turnaround time and commercial terms still matter. The test has exposed something the fleet list could not: apparent completeness can conceal unsupported assumptions.
Score each task as demonstrated, demonstrated with manual intervention, unsupported, or not tested. Record preparation time separately from review time. Allow suppliers to explain why an input is insufficient; do not reward a system simply for producing a number on every row.
Repeat one assessment from an exported evidence package. If another qualified reviewer cannot identify the inputs and method, ask the supplier to close that gap before expanding the evaluation.
4. Include Ownership, Cost and Boundaries
Request written answers about data retention, access removal, backup recovery, export formats, implementation work and support. Price the workflow over a realistic period, including data cleanup and engineering review. A low subscription price can coexist with substantial manual preparation.
Have the owner's IT and operational-technology teams review the proposed connections, access roles and update arrangements. In the evaluation environment, demonstrate removal of a departing user's access and recovery of an agreed backup. A feature list alone does not show that either works with your deployment.
Set a decision date and define which weaknesses block purchase. Incorrect asset association and hidden substitution of missing measurements deserve different treatment from a cosmetic reporting preference. Keep the blocking list short enough to use and specific enough to verify.
A demonstration cannot establish long-term failure prevention, and a score cannot authorize switching or continued operation. Those decisions remain with the asset owner's engineering and operating procedures. The next step is to assemble the sample records and agree the acceptance evidence before inviting demonstrations.
To discuss your laboratory data and assessment workflow, talk to an engineer.
Sources and Scope
- IEEE C57.143-2024: edition and published scope verified; full-text requirements not assessed here.
- CIGRE Technical Brochure 761, 2019: public catalogue summary on fleet assessment indices checked; no full-text requirements or numerical score bands reproduced.
- W3C PROV overview, 30 April 2013, Working Group Note, abstract and introduction: provenance terminology, not a procurement mandate.
Evidence checked on 30 September 2026. Examples and evaluation criteria are original editorial suggestions, not a completed supplier trial.
Cover: AI-generated editorial illustration of an evidence-review desk overlooking a transformer yard. Not a customer site, actual laboratory record, software screenshot or validated electrical layout.
Cover photograph: Zetes-3 power station control room; not a Seetalabs software interface. Photo: Zhangmin16 / Wikimedia Commons, CC BY-SA 4.0. Commons download, resized where applicable; no editorial retouching. Illustrative photograph, not a Seetalabs customer case or evidence of the results discussed.
