Home
Hydraulic dynamometer
Test data / records and traceability
A test result is not the number on the report; it is the number plus everything needed to defend it. That includes what the channel meant, which units were used, which calibration was in force, which configuration produced it and which raw samples it came from. When those are missing, a report is an assertion rather than evidence.
This guide follows the path from a defined channel to a published report: channel definition and units, calibration and configuration versioning, the difference between raw, filtered and calculated values, identity records, and the audit trail that lets someone reproduce a report months later. It does not describe HD-3000 data formats, user permissions or backup functions, because those must come from the supplied documentation for the installed system.
01 / DEFINITIONSChannel definition and units
A channel name is not a definition
Oil pressure is a label, not a specification. A usable channel definition states the quantity, the location of the measurement, the sensor type, the range, the unit, the sign convention and the scaling that converts the raw signal into the engineering value. Without the location, two pressure channels can be confused forever; without the sign convention, a torque sign error survives review.
The definition belongs in a controlled document that the report can reference by version. A definition kept only in the acquisition configuration is effectively invisible to anyone reading the report, and it disappears when the configuration is replaced.
Units and scaling deserve their own check
Most data errors that reach a report are not measurement errors; they are scaling errors. A factor applied without an offset, a millivolt range interpreted as a current loop, a pressure in bar presented as kPa, a torque in newton-metres converted with the wrong constant. A short unit and scaling check at configuration time is cheaper than a recall of the results.
Conversions should be explicit and versioned too. If a report shows brake-specific fuel consumption, the density, the lower heating value and the conversion constants used are part of the method, not hidden inside a spreadsheet.
| Definition element | Why it must be recorded | Typical failure when missing |
|---|---|---|
| Quantity and location | Distinguishes similar channels | Two pressures confused across builds |
| Sensor and range | Bounds the valid measurement | Out-of-range values treated as data |
| Unit and sign | Makes values comparable | Torque sign or unit errors |
| Scaling and offset | Reproduces the engineering value | Factor applied, offset omitted |
| Calculation basis | Defends derived values | BSFC or corrected power cannot be rebuilt |
Define derived channels as formulas, not as numbers
Every calculated channel should exist as a formula with named inputs, and the report should carry the formula version. That is what allows a reviewer to recompute a value when one input is later found to be wrong. A derived value stored only as a column of numbers cannot be recomputed, only trusted.
02 / VERSIONSCalibration and configuration versioning
Records only mean something against a calibration state
A measured value is only as good as the calibration in force when it was taken. NIST's guidance on calibration intervals makes the practical point directly: recalibration reports should include the as-submitted and post-calibration data, because those records are what allow an interval to be validated or refined. For a test record, the equivalent is the calibration identifier and its validity at the time of the run.
That identifier needs to travel with the data. A test report that says torque calibrated without the certificate reference and date cannot be reconciled with the calibration file, and a later reviewer cannot tell whether the instrument was in or out of its interval.
Configuration is part of the result
The acquisition configuration includes channel definitions, sample rates, filter settings, alarm limits and the sequence that was executed. Two runs with different configurations are not comparable, even if the engine and the set points were identical. Versioning the configuration and stamping every run with it is what makes that comparison possible.
ISO/IEC 17025 frames the same idea at the laboratory level: it sets out requirements for competence, impartiality and consistent operation so that testing and calibration results remain reliable and traceable (ISO/IEC 17025:2017). A test cell is not necessarily an accredited laboratory, but the record logic is the same.
Keep the change history, not only the current state
A version number alone tells a reader that something changed; it does not tell them what. A short change history, dated and attributed, is enough for most cells and saves hours when a result has to be explained.
The release side of the same problem is covered by the hydraulic dynamometer maintenance checklist, where calibration and condition records decide whether a run may proceed at all.
03 / DATA LAYERSRaw, filtered and calculated data
Three layers, three purposes
Raw data is what the acquisition hardware produced. Filtered data is what the operator saw and what the control loop acted on, and it is typically delayed. Calculated data is what the report publishes. Each layer answers a different question, and a workflow that keeps only one of them loses the ability to answer the other two.
Keeping all three is not free. Storage, backup and retrieval all cost effort, so the decision should be made per test type rather than by default.
Filtering changes the meaning, not just the appearance
A filter that steadies a display also delays the value, and a delayed value compared against an unfiltered channel produces a timing error as well as an amplitude one. If the filter setting is not recorded, a reviewer cannot distinguish a real transient from a smoothing artefact.
The same applies to resampling and averaging. A report point computed from a one-second average is not the same measurement as the peak in that second, and the report should state which one it publishes.
Recording the filter and resampling settings per channel, together with the run, closes that gap. It also makes the report's smoothing choices auditable, which matters when two sites compare results from the same engine.
Preserve enough raw data to answer a later question
The useful test is not could we rebuild this report but could we answer a question nobody thought of. That argues for preserving the raw samples for the channels that define the test, with their timestamps, and for keeping them linked to the run identity rather than to a filename convention.
04 / IDENTITYTest IDs, serial numbers and operator records
Identity is the spine of the record
A run needs an identifier that is unique, stable and never reused. It should be linked to the engine serial number, the configuration version, the sequence version, the calibration identifiers and the people involved. When identity is carried only by a filename, a rename breaks the chain.
| Identity field | Links the run to | Why it matters |
|---|---|---|
| Run identifier | Everything else | Only reliable join key in the record |
| Engine and serial number | The physical object tested | Distinguishes units with the same build |
| Configuration version | Channel definitions and settings | Explains comparability |
| Sequence version | The executed procedure | Distinguishes intent from execution |
| Calibration identifiers | Instrument validity | Supports the measurement claim |
| Operator and reviewer | Responsibility | Answers who accepted the result |
Operator records are evidence, not bureaucracy
Who set up the cell, who ran the test, who accepted the result and what they observed are all part of the evidence. Notes written during a run carry information that no channel captures: a noise, a smell, a connector that was reseated, a decision to repeat a point. Those notes should attach to the run identifier, not to a personal notebook.
Keep the deviations visible
A record that shows only the planned sequence hides what actually happened. Skipped points, repeated points, aborted modes and manual overrides all need to appear, with timestamps, so the report reflects the run rather than the intention.
The engine dyno testing procedure defines what a planned run contains, which is the baseline those deviations are measured against.
05 / REPORTSReport generation and audit trail
A report should be reproducible, not just readable
The test of a good report is whether a competent engineer, given the record, could regenerate the same numbers. That requires the formulas, the inputs, the units, the calibration state and the configuration, all referenced rather than restated. A report that quotes a result without those references cannot be regenerated, only believed.
The engine dyno test report guide covers how the published values are normally laid out; the workflow described here is what makes those values reproducible.
The audit trail needs to survive the report
Reports get edited. A published number can change because a scaling error was found or a calibration was superseded. What keeps the record honest is the trail: who changed what, when, and on what basis. Without it, the latest version of a report silently becomes the only version.
NIST's emphasis on as-submitted and post-calibration data is the same principle applied to instruments: the history is the evidence, not the final state. A cell that keeps only current values is keeping conclusions and discarding the reasoning.
Decide retention before something is lost
Retention is a decision with an owner, a duration and a disposal rule. It should cover the raw data, the configuration and calibration references, the sequence records and the reports, and it should be consistent with the customer's and the regulator's requirements. A retention policy invented after a dispute is not a policy.
Share the channels, the report format and the retention your programme requires, and Hance can help define a data workflow that keeps the evidence with the result.
Discuss your test data workflow
Questions and answers
What must be stored with a test result?
The run identifier, engine and serial number, configuration and sequence versions, calibration identifiers valid at the time, the channel definitions and units, the formulas for derived values, the executed deviations, and the names of the people who ran and accepted the test. Without those, the number is an assertion.
Should raw data be preserved?
For the channels that define the test, yes, with timestamps and the run identity. Raw data is what allows a report to be re-derived when a scaling, a filter or a calibration question arises. Where storage is limited, decide explicitly which channels are essential rather than trimming silently.
How can reports be reproduced later?
By keeping the formulas and their versions, the exact input channels and units, the calibration state and the configuration version, all linked to one run identifier. A report that restates numbers instead of referencing them cannot be reproduced, because the reasoning behind the numbers is missing.
Who owns the data?
The contractual arrangement between the facility and its customer decides, and the retention plan should state it explicitly. The technical system should support the answer rather than determine it.
How long should data be kept?
Long enough to satisfy the customer, the regulator and any warranty or dispute process that could refer to it. The duration is a decision to make with those parties in advance, not a default setting to discover later.
Technical references
NIST — Recommended Calibration Interval: interval inputs, and the value of as-submitted and post-calibration records.
ISO/IEC 17025:2017 — General requirements for the competence of testing and calibration laboratories: requirements for competence, impartiality and consistent operation supporting reliable, traceable results.
This article describes general data-workflow and traceability practice. It is not a HD-3000 data-management specification, not a retention policy and not an accreditation claim. Confirm formats, permissions, backup and retention with the equipment documentation and the responsible quality function.