Performance Curves Need a Home: Technical Data in Product Configurators

Flat illustration of a man with a magnifying glass presenting a clipboard with bar and pie charts, in blue tones

By Roman Perich

An engineering configurator does not only list options. It computes: it reads a pump curve, finds the duty point, checks NPSH, picks the motor. The data it computes with — performance curves, sizing tables, test results — is the most valuable data a manufacturer has. It is also the data that most often has no proper home.

What counts as technical data

Performance curvesHead, efficiency, power and NPSH over flow — per size and impeller
Sizing tablesLimits, ranges and selection tables engineering works with
Test and certification dataMeasured values, tolerances, approvals per series

All three have one thing in common: they are datasets, not attributes. They have points, ranges, versions and units — and they change whenever engineering learns something new.

Technical data is not a list of attributes. It is datasets with points, versions and units.

Why it does not belong in a PIM

A PIM is built for commercial product information: articles, attributes, texts, images, prices. A performance curve is something else — a set of points that is interpolated, scaled for impeller diameters and speeds, and replaced when a new measurement comes in. Squeezed into PIM attributes, it loses exactly what makes it useful.

And not inside the configurator either

The other temptation is to load the curves straight into the configurator. Then the same curve is needed by the datasheet, by the selector on the website and by the sales engineer’s sizing tool — and there are three copies of it, each updated at a different time. The island problem, again, with the data that matters most.

Technical data needs its own home, its own owner and its own update path — decided before you need it, not when the first curve changes and nobody knows where to put it.

A home, an owner and an update path

A homeA technical data store behind the same API as the product data — one source for every channel
An ownerA named engineer per series who is responsible for its curves and tables
An update pathA defined way from new measurement to released data

The update path is where most companies improvise. Written down, it has four steps:

MeasuredNew curve from the test bench or the supplier
ValidatedChecked by the engineer who owns the series
VersionedStored with date, source and unit — never overwritten
ReleasedFor this series only, visible in every channel at once

Each step has a name attached to it. If a curve turns out to be wrong, you know who released it, when — and which quotations were based on it.

Every new curve is checked, versioned and released — for its series only.

One declared unit per quantity

Curves arrive in whatever unit the test bench or the supplier used. That is where wrong configurations start: flow in m³/h in one table and l/s in another, head in metres here and feet there. Store one canonical unit per quantity, with the unit declared — and convert only on the way out:

QuantityStored asShown to the user as
Flow ratem³/hm³/h, l/s, l/min, US gpm
Headmm, ft
Pressurebarbar, kPa, psi
PowerkWkW, hp
Temperature°C°C, °F

Every conversion then lives in one place, in code or behind the API — tested once, instead of repeated in a rule, a spreadsheet formula and a screen field with slightly different rounding each time.

What to ask before you buy

  • Where do performance curves and sizing tables live — and who maintains them?
  • Can the same curve serve the configurator, the datasheet and the website without copies?
  • Is every curve versioned, with source, date and unit?
  • Is every quantity stored in one declared unit, and where do conversions happen?
  • How does a new measurement get from the test bench into a quotation?

These are questions 9 and 12 of our buyer’s checklist for product configurators. Where the rest of the product data should live is covered in Your Configurator Should Not Own Your Product Data.