Home
Hydraulic dynamometer
Instrumentation / engine interface
Engine control module data is the second opinion a dynamometer cell usually lacks. The torque transducer measures what the shaft did; the ECM reports what the engine believed it was doing, which fuel quantity it commanded, which limit it was sitting against and whether a fault was already active. Bringing those two views into one record is worth the effort, but only if the integration is designed rather than improvised.
This guide covers why ECM data complements physical sensors, how CAN and J1939 channels are mapped into a test configuration, how bus data is placed on the same time base as the analogue channels, how missing and implausible signals are handled, and what the data is actually good for once it is in the record. It does not state which protocols HD-3000 supports, how many bus channels it offers, or what an engine manufacturer will authorise. Those are configuration and permission matters for the controls team and the engine supplier.
01 / WHY IT HELPSWhy ECM data complements physical sensors
The sensor measures the result; the ECM reports the intent
A torque transducer tells you the shaft produced a value. It cannot tell you that the ECM was commanding a fuel quantity at its smoke limit, that the turbocharger was at its speed limit, or that a derate was active because a sensor elsewhere had failed. Those are statements about intent and protection state, and they exist only in the controller.
That difference matters most when a result is unexpected. A torque shortfall with no ECM derate looks like a mechanical or fuelling problem; the same shortfall with an active torque limit looks like a calibration decision. Without bus data, the second interpretation is unavailable and the investigation starts in the wrong place.
ECM data is not a substitute for measurement
The controller's reported values are calculated or modelled quantities, not measurements. A reported fuel rate may be a commanded quantity rather than a measured mass flow, and a reported torque may be an estimate derived from fuelling and speed. Using those values as if they were measured quantities quietly replaces the test's measurement basis with the controller's model.
The safe pattern is to treat ECM channels as context and cross-check, while the physical instruments remain the reference for the quantities the report publishes. Where an ECM value and a measured value disagree, that disagreement is itself useful information, and it should be preserved rather than averaged away.
Decide which channels earn a place in the record
Bus bandwidth is finite and every mapped channel carries a maintenance cost. A practical selection rule is to map what the report or the diagnosis actually needs: commanded fuel or torque, engine speed as reported, coolant and oil temperature as reported, active derate or limit flags, fault codes and their state, and any signal the test procedure explicitly controls. Everything else can be captured on demand.
02 / MAPPINGCAN/J1939 channel mapping
Understand what a parameter group is before mapping it
Heavy-duty engines commonly publish data using SAE J1939, which Vector's overview describes as an open standard built on CAN physical layers, using the 29-bit extended identifier, standardised baud rates of 250 kbit/s and 500 kbit/s, parameter groups with defined cycle times, and a transport protocol for messages longer than eight bytes.
The practical consequence for mapping is that a signal is not a free-standing number. It arrives inside a parameter group, on a cycle, from a source address, with a scaling and an offset that must be applied exactly. Two signals from different groups have different ages even when they appear in the same row of your table.
| Mapping element | What it decides | Where integration usually fails |
|---|---|---|
| Source address | Which controller the data came from | Two controllers publishing the same parameter |
| Parameter group and cycle | How often the value updates | Assuming every signal updates at the fastest rate |
| Scaling and offset | The engineering value | Applying a factor but not the offset |
| Unit and sign convention | Comparability with measured channels | Mixing rpm and rad/s, or torque sign |
| Transport handling | Whether long messages arrive complete | Partial or reordered multi-packet data |
Request data explicitly where the standard allows it
Not every value is broadcast continuously. Some are available only on request, which means the integration has to decide when to ask, how often, and what to do when the answer does not come. A request loop that runs faster than the controller can answer fills the bus with duplicates and produces a channel that looks alive while carrying stale values.
Where a value is only available on request, the record should say so. A reader who assumes a one-second update from a broadcast group will misinterpret a value that actually updates on request.
Keep the mapping as a controlled document
The mapping table is the interface between the test cell and the engine, and it changes whenever an engine variant or a software version changes. It needs a version, an owner and a review trigger. A mapping held only inside a configuration file is difficult to audit and easy to break silently.
03 / TIMETime synchronization with dyno channels
Two clocks produce false correlations
Analogue channels are sampled by the acquisition hardware. Bus values arrive when the controller decides to send them. If both are shown on one plot without a common time base, a reader will compare a torque sample with a fuelling value that may be tens or hundreds of milliseconds older, and will attribute the difference to the engine.
HBK's explanation of PTP describes the stronger approach: IEEE 1588 PTPv2 uses hardware timestamping and can hold sub-microsecond alignment between participating devices, while network protocols without hardware stamping cannot make the same claim. For a test cell, the useful question is not which protocol is fashionable but whether each channel's timestamp comes from hardware or from software.
Hardware stamping and arrival-time alignment are different promises
Dewesoft's engine test bench case study shows both approaches in one system: analogue channels and CAN-FD data are acquired in the same hardware with hardware-stamped analogue values, while FlexRay data is soft-synchronised using the arrival time of its messages. The case study is a supplier example, not a Hance specification, but the distinction is general and worth reproducing in any integration.
The consequence is documentary. If some channels are hardware-stamped and others are aligned on arrival, the report should say which is which. Otherwise a later reader will assume a precision the data does not have.
Verify alignment with an event you can see in both streams
A step change in speed, a load application or a commanded fuel step appears in both the physical and the bus record. Their relative order and interval are a direct check on alignment. If the ECM's reported speed appears to lead the measured speed by a suspiciously constant amount, the mapping or the timestamping is worth investigating before any conclusion is drawn from the comparison.
04 / VALIDATIONSignal validation and missing-data handling
Bus values fail differently from analogue values
An analogue channel fails by going open, shorted or noisy. A bus value fails by stopping, by freezing at its last good value, by arriving with a fault status, or by continuing to arrive while the controller reports that the sensor behind it is invalid. The last case is the dangerous one, because the number looks perfectly healthy.
J1939 includes fault and status information alongside data, and a working integration uses it. A channel whose source is flagged invalid should not be plotted as a clean trace; it should carry its status into the record so the reader can see that the value was reported but not trusted.
Define what happens when data stops
Every mapped channel needs a timeout and a defined consequence. Options include holding the last value with a marker, substituting a defined invalid value, raising a warning, or inhibiting the part of the test that depends on it. What is not acceptable is a silent continuation that leaves a flat line in the data and no note in the report.
The same discipline applies to partial data. A multi-packet message that arrives incomplete should be discarded, not partially used, because a partially decoded parameter group can produce a plausible but wrong engineering value.
Cross-check the bus against the instruments
A continuous cross-check between reported and measured values is the cheapest validation available. Reported coolant temperature against a measured coolant temperature, reported speed against measured speed, reported fuel rate against measured fuel consumption. Persistent offsets point to scaling or to a different definition; intermittent disagreement points to timing or to a failing sensor on one side.
05 / USEUse in diagnostics and automated reports
Bus data shortens the diagnosis
The most immediate benefit of ECM data is during an unexpected result. An active derate flag, a torque limit, a smoke limit or a fault code explains in one line what would otherwise take a shift of investigation. The engine dyno test report guide covers how those findings are usually presented alongside the measured values, and the engine dyno testing procedure covers the run-setup discipline that makes the comparison valid.
Automated reports need the same validation as the plot
An automated report that quotes an ECM value without its status is a risk. If the value was flagged invalid, the report should say so; if it came from a request channel, the report should state the update basis. Reports generated by the test software are read by people who did not see the live screen, so the status information has to travel with the number.
Keep the raw bus log
A decoded bus channel is convenient and lossy. Keeping the raw log, with its timestamp and source address, allows a later reviewer to re-decode a parameter, check a scaling, or examine a message that was not mapped at the time. For durability programmes that run for weeks, that decision is what makes a retrospective question answerable at all.
Share the engine variant, the communication database and the channels your reports depend on, and Hance can help define an interface and recording approach that fits the installation.
Discuss your ECM data integration
Questions and answers
Can ECM data replace external sensors?
For some context channels, yes; for the quantities a report publishes, no. The controller's values are calculated or modelled, and their validity depends on the controller's own sensors. Use them to interpret and cross-check measured values, and keep the measurement basis for anything that has to be defended.
How are CAN channels synchronized?
Either by collecting the bus data in the same hardware that samples the analogue channels, with hardware timestamps, or by aligning the two streams afterwards using message arrival times. The first gives a stronger claim. Whichever is used, the report should state the method per channel so a reader knows which comparisons are supported.
What information is needed from the engine OEM?
The communication database and its version, the parameter groups and request behaviour, the scaling and units, the fault and status definitions, the controller software variant, and the authorisation to read the bus in the first place. Without the authorisation, a technically perfect integration is still not permitted.
What should happen when a bus signal disappears?
A defined timeout with a defined consequence, recorded in the data. Hold-with-marker, invalid substitution, warning or test inhibition are all acceptable choices when they are chosen deliberately and documented. A silent flat line is not.
Should the raw bus log be kept?
Yes, where storage allows. The decoded channel is what the report uses; the raw log is what allows a later reviewer to verify the decoding, examine an unmapped message and check the source address. It is also the only way to answer a question that nobody thought to map at the time.
Technical references
Vector — SAE J1939 know-how: 29-bit identifiers, 250/500 kbit/s, parameter groups, transport protocol for messages over eight bytes.
Dewesoft — Synchronized combustion and NVH measurements on an engine test bench: analogue and CAN-FD data in one hardware, hardware-stamped analogue data, arrival-time alignment for other buses.
HBK — Precision Time Protocol in data acquisition and testing: PTPv2 hardware timestamping and sub-microsecond alignment.
This article describes general ECM and CAN integration practice. It is not a HD-3000 protocol specification, not a statement of which parameter groups an engine will expose, and not an authorisation to read any vehicle or engine bus. Confirm the supported interfaces, the communication database and the permission with the equipment documentation, the controls team and the engine manufacturer.