Test execution / durability programmes
An automated engine test sequence replaces a series of operator decisions with a defined list of operating points, transitions and conditions, executed the same way every time. That is the whole point: not that the machine runs by itself, but that two runs, two shifts and two sites produce records that can be compared without arguing about how the test was driven.
This guide covers the building blocks of an automated sequence, how conditional steps and interlocks differ, where the boundary of unattended running actually sits, and what a sequence record has to contain before repeatability means anything. It does not describe HD-3000 automation functions, unattended-operation approvals or safety certification. Those are configuration and site-approval matters that must come from the supplied documentation and the responsible authority.
01 / EXECUTIONWhy manual testing produces variation
The operator is part of the measurement
A manual durability run has a human in the loop for every transition. That person decides when the engine has stabilised, when to move to the next point, how fast to open the throttle, and what to do when a reading looks odd. Reaction time, interpretation of the procedure and even the time of day all enter the data.
SuperFlow's review of automated dynamometer testing puts the same point plainly: manual methods introduce variability through operator reaction time, differing interpretation of procedures and changing environmental conditions, while automation executes predefined procedures with precise control over speed, torque, throttle position and data acquisition parameters.
Variation is invisible until you compare runs
A single run driven by hand looks perfectly reasonable. The problem appears later, when a durability programme compares run 3 with run 40 and treats the difference as a component effect. If the transition rate differed, or the stabilisation interval was cut short on a busy afternoon, the comparison contains an execution difference that no amount of post-processing can remove.
What automation actually removes
Automation removes execution variation, not measurement error. It cannot correct a torque offset, a mis-scaled pressure channel or a cooling supply that drifts. Those remain the subject of calibration and cell-condition work, which is why sequence design and measurement traceability have to be treated as separate but cooperating disciplines.
02 / BUILDING BLOCKSSet-point, ramp and cycle building blocks
Four building blocks cover most sequences
Almost every automated engine sequence is assembled from the same small vocabulary: a set point that defines where to go, a transition that defines how to get there, a dwell that defines how long to stay, and a repeat or loop that defines how many times the whole thing runs. Parameters recorded per block at the start of a run are what make the sequence reproducible.
A published cycle shows the same structure
ISO 8178-4 is a useful public example because its structure is explicit. Its steady-state cycles are sequences of modes, each mode a speed and torque set point with a weighting factor over the cycle. The ramped mode cycles added in the 2017 edition go further: each steady-state mode is separated by a twenty-second transition in which torque and speed progress linearly from the previous setting to the next, and the transition time counts as part of the new mode.
DieselNet's summary of ISO 8178-4 also notes a detail that matters for durability work: in some cycles the modes are not run in the same order as the discrete version, or a mode is split, specifically to prevent extreme changes in temperature. That is a sequence-design decision, not a measurement error, and it belongs in the procedure document rather than in someone's memory.
| Building block | What it defines | What the record must capture |
|---|---|---|
| Set point | Speed, torque or another controlled condition per mode | Command values and the control variable used |
| Transition | How the next set point is reached | Rate or duration, and whether it is linear or stepped |
| Dwell | Time held at a set point before recording | Stabilisation criterion and the actual dwell time |
| Repeat | How many cycles, and what constitutes one cycle | Cycle count, sequence version and any skipped elements |
Stabilisation criteria drive everything downstream
A dwell only exists to answer a question: is the operating point stable enough to record? The criterion is a decision, so it should be written down as one, for example a rate-of-change threshold on torque and coolant temperature over a stated window. Without a stated criterion, an automated sequence executes dwells that only look consistent.
Order and grouping belong to the engineering
The ISO example's reordering to avoid extreme temperature excursions is worth copying as a habit rather than as a specific sequence. A durability cycle that swings between a very high load and idle every few minutes will produce a different thermal history from one that steps through intermediate points. Both may be repeatable; only one may represent the duty being simulated.
03 / CONDITIONS AND INTERLOCKSConditional steps and safety interlocks
Conditional logic is where sequences stop being lists
A simple sequence is a table of set points. A useful one branches: if a temperature has not stabilised within the expected window, wait longer or abandon the mode; if a measured value crosses a limit, decide whether to hold, reduce load or stop. SuperFlow's description of complex automated testing lists conditional logic, automated decision criteria and safety monitoring among the capabilities programmable test software may combine, which is exactly the point at which a sequence becomes a control design rather than a script.
Every branch needs a written rule. If the reading is bad, stop is not a rule, because two engineers will disagree about bad and about stop. A rule states the channel, the condition, the persistence required and the action.
Alarm, interlock and protection are three different things
An alarm notifies. An interlock prevents an action from happening or forces a safe state. A protective function is the engineered layer that is intended to remain effective when everything else misbehaves. Tests get into trouble when a sequence's programmable alarm is treated as the protective layer.
Power Test's notes on test cell safety describe the equipment side: an emergency shutdown system with accessible stop devices, safety alarms, and data acquisition systems whose programmable channel alarms can operate relays that close fuel lines or change fan and valve states, plus separate fire suppression and guarding. They also list example alarm set points, and those values must not be copied into another site's cell, because the applicable limits come from the engine and equipment documentation.
| Layer | Typical function | Evidence a reviewer should expect |
|---|---|---|
| Alarm | Warn the operator or the sequence logic | Channel, threshold, persistence, who sees it |
| Interlock | Prevent an unsafe transition or restore a state | Condition, action, proof it acted |
| Protective function | Remain effective independently | Design basis, test evidence, independence |
An interlock that has never been tested is a hypothesis
Automated sequences make it easy to trust logic that has only been reviewed on paper. Each interlock needs a defined verification: trip it deliberately under controlled conditions, confirm the action and the recorded timestamp, and record the date and the result. Adding a rung to a sequence should trigger the same discipline as adding a protective device to the machine.
04 / UNATTENDED LIMITSUnattended-test boundaries
Automation and unattended operation are different permissions
A sequence that runs to completion without operator input is an automation capability. Running a cell with nobody present is an operating permission granted by the site, its fire and safety arrangements and, where applicable, the insurer and the enforcing authority. The first does not imply the second.
Conditions that belong before any unattended run
At minimum, an unattended arrangement requires a defined safe state that the sequence returns to on abnormal conditions, interlock monitoring that does not depend on a display being watched, fire detection and suppression appropriate to the fuel in use, ventilation and atmosphere monitoring where applicable, and a defined response to loss of services. It also requires a way to stop the test that does not rely on someone travelling to the cell.
The engine and cell documentation, not a blog article, defines whether those conditions are met. Where any of them is absent, the honest position is that the run is attended.
What cannot be delegated to a sequence
Sequence logic can hold a set point, apply a ramp and react to a defined condition. It cannot judge whether an unusual noise is normal, whether a vibration reading is credible, or whether a fuel smell means something. Those judgements need a person or a different, engineered detection layer. A programme that removes the operator without replacing the judgement is not automated, it is unsupervised.
05 / REPEATABILITYRepeatability and automated reporting
Repeatability is executed, not measured
Two automated runs of the same sequence can still differ. The sequence guarantees the intended transitions; it cannot guarantee that the cooling supply behaved the same way, that a sensor did not drift, or that the engine's mechanical condition was unchanged. Repeatability therefore needs evidence from both sides: the sequence record showing identical execution, and the measurement records showing stable conditions and valid calibration.
The engine dyno test report guide and the engine dyno testing procedure describe the reporting and run-setup side; the torque calibration record supplies the measurement side. The data acquisition channel and timing guide supplies the third: which channels were hardware-synchronised and at what rate. Add that internal link once it is published.
The sequence record makes deviation visible
A sequence report that shows only the set points is not a report. It should show the sequence identification and version, the set points, transitions and dwell criteria as executed, every branch taken, every deviation and every abort, the recorded timestamps of the transitions, and the instrument calibration status at the time of the run. Where the test programme requires a witness or an approval, that belongs in the record too.
Automated reporting is only an advantage if it represents the run that happened. A clean summary generated from the intended sequence, rather than the executed one, is worse than a messy log, because it hides exactly the deviation the automation was supposed to control.
Share the durability cycle, the operating limits and the way your cell is supervised, and Hance can help define a test sequence and monitoring approach that fits the installation rather than a generic template.
Discuss your automated test sequence
Questions and answers
What should an automated sequence control?
It should control the operating point, the transition between points, the dwell and the repeat logic, and it should decide what to do when a condition is not met. Control of speed and torque is the visible part; the written branch rules and the stop conditions are what make the sequence dependable.
How are abnormal conditions handled?
By rules that are written before the run: which channel, which condition, how long it must persist and what action follows. The action may be hold, reduce load or stop, and it should be logged with a timestamp. A sequence that stops on an undefined condition has handled nothing.
How can two operators run the same test consistently?
By not letting either of them drive it. The sequence and its parameters should be a controlled document, and the run should record the executed sequence rather than the intended one. Automation reduces operator-dependent variation; the record is what proves it did.
Can a test cell run unattended overnight?
Only where the site has approved unattended operation and the necessary detection, suppression, monitoring and stop arrangements are in place and verified. Automation capability alone is not that approval, and the decision belongs to the responsible authority, not to the test engineer or the supplier.
What belongs in an automated test record?
Sequence identification and version, the executed set points, transitions and dwell criteria, branches taken, deviations and aborts with timestamps, and the calibration status of the instruments involved. Without the executed sequence, a record cannot distinguish a component change from an execution change.
Technical references
- DieselNet — ISO 8178-4 emission test cycles: discrete-mode cycles, ramped mode cycles with 20 s linear transitions, mode reordering to limit temperature excursions.
- Power Test — Engine test cell safety: alarms and system protection: emergency shutdown, alarms, programmable channel alarms operating relays, fire suppression and guarding.
- SuperFlow — Why automated dynamometer testing matters: sources of manual variability, predefined procedures, conditional logic and test types.
This article describes general automated-sequence practice. It is not a HD-3000 automation specification, not an approved unattended-operation plan and not a safety assessment. Confirm available functions, interlocks, stop arrangements and site permissions with the equipment documentation and the responsible engineering and safety functions.

Home
Hydraulic dynamometer