Test before the machine

For each requirement, choose a nearby case that should fail to activate it. If Start is accepted only with a carton at pickup, test a fresh Start with pickup absent. If an acknowledgement clears a completed state, test that same acknowledgement during motion. These negative cases reveal missing gates much more reliably than repeating the normal cycle ten times.

A test starts with a claim

“It runs in simulation” is an observation, not a test result. What ran? From which initial condition? Which behavior did you expect? What evidence would have made you reject the program?

Consider a model conveyor transferring one tray into an empty station. The requirement says: when a fresh transfer request is accepted, run the conveyor until the station sensor confirms arrival; if arrival is not confirmed within four seconds, withdraw the request and report a transfer timeout. After interruption, do not retry without an explicit recovery decision.

That paragraph already contains several tests. One happy animation cannot cover them. A deliberate test plan turns each claim into a repeatable experiment before anybody asks the physical machine to move.

Make a small traceability table

Give requirements stable identifiers. They are not decoration; they let you ask what changed when a customer revises a sentence.

“Defined control evaluation” matters. An input image, task execution, fieldbus exchange, drive response, and mechanical stopping are different stages. A software scan test can prove the program's decision at a sampled input. It cannot prove the physical stopping distance of a real conveyor.

Control time rather than waiting for it

A useful test harness owns a clock and a plant model. You advance one control evaluation, inspect the output request, advance the plant, and repeat. State clearly whether the harness samples sensors before or after each plant update. Otherwise a one-scan discrepancy can look like a timer defect.

For a four-second timeout with a ten-millisecond model task, inspect the evaluations immediately before, at, and after the configured boundary. Do not assume that every real target updates elapsed time using an exact integer scan counter. Timer behavior belongs to its implementation and task scheduling. For example, Beckhoff documents that its standard TON resets when IN is false and asserts Q when the input remains true for the specified interval. Use the actual target documentation when porting the test. Beckhoff TON reference.

The portable claim is not “exactly scan 400.” It is “the timeout condition is recognized according to the selected timer and control scheduling, within the response budget specified for this application.” The model can use exact steps while openly identifying that simplification.

Give simultaneous events a policy

Suppose arrival and timeout become true in the same sampled evaluation. Which wins? There is no universal answer hidden inside Structured Text. You must decide the intended meaning.

For our training transfer, choose confirmed arrival before timeout, because arrival at the allowed boundary counts as successful delivery. Write that decision into both implementation and test. If the process requires an earlier deadline, make the opposite choice and explain it. Accidental source-code order should not be the only specification.

Given: Transfer is active and elapsed time reaches the limit.
When: Arrival is true in the same sampled input set.
Then: Enter Delivered, with no transfer-timeout alarm.

This tiny case is valuable because it tests an ambiguity that a long normal run may never expose.

Test what the sensor can lie about

Fault injection means controlling a failure deliberately in the model. Disconnecting a Boolean logically is different from making its physical target disappear. Give the model separate physical truth and measured feedback. Otherwise “stuck sensor” simply moves the tray in the simulation, which teaches the wrong relationship.

Test arrival stuck false, arrival stuck true before starting, a short pulse during transfer, and an impossible combination of presence sensors. For each case, decide whether the program detects a fault, blocks acceptance, completes incorrectly, or cannot distinguish the situation with available instrumentation. The last answer is allowed. Software cannot infer information the machine does not provide.

Inject communication loss and stale data separately if the design uses remote signals. A false value and an old true value can produce different failures. Include data validity and age in the contract rather than assuming every received number is trustworthy forever.

Keep assertions independent of the implementation

A weak test reads the program's State and repeats the same conditions used to calculate it. Both can be wrong in the same way. Stronger tests check external commitments: whether motion was requested without permission, whether two incompatible requests occurred together, whether accepted work was eventually completed or faulted.

Internal state is still useful evidence. Log it to explain a failure, but derive acceptance from requirements. In a transfer test, record the request, acceptance, source presence, destination presence, motor request, completion, and alarm reason. A trace gives you the story when a final Boolean does not.

Separate model assumptions from acceptance criteria. Frictionless motion, perfect sensing, and instant motor response may be reasonable simplifications for a sequencing lesson. They are not characteristics you have verified on hardware.

Test the path back

A fault test is unfinished until recovery has been exercised. After timeout, clear the simulated obstruction. Confirm that nothing starts. Acknowledge the alarm; confirm that acknowledgement alone does not start motion. Establish the model's recovery conditions, reset, and send a fresh request. Verify one transfer, not two.

Power-cycle tests need the same discipline. Which values are retained? Which physical conditions remain while software initializes? A retained Transferring state with a cleared transaction identifier is not a complete recovery strategy. Test initialization from every physically plausible combination, including one you hoped would never happen.

Try it

The tray reaches the station at 3.95 seconds. Its arrival sensor becomes true for one ten-millisecond evaluation, then false. The specification requires presence to remain true for fifty milliseconds before delivery is accepted. The transfer deadline is four seconds.

Write three tests: one for this brief pulse, one for stable arrival that starts at 3.94 seconds, and one for stable arrival that starts at 3.97 seconds. State your deadline interpretation before predicting the results.

Work through the answer

Choose the deadline to apply to confirmed presence, not the first unqualified sensor edge. The brief pulse must not count as delivery. Its qualification timer resets when presence disappears, so timeout follows if no later valid arrival occurs.

Stable presence beginning at 3.94 seconds can qualify by approximately 3.99 seconds in the simplified clock model and should complete before the deadline. Stable presence beginning at 3.97 seconds cannot qualify until approximately 4.02 seconds, so it misses this contract. Sampling details must be captured in the executable test harness.

If the customer intended the deadline to mean first physical contact with the sensor, this specification needs revision. Testing exposed the disagreement while it was still cheap. Preserve the trace, requirement version, and result for commissioning with evidence.