Machine Design #51: Interface Control — A Station Handshake Should Not Be a Few Loose Bits

An I/O list can tell you that Station A has a “ready” bit and Station B has a “start” bit. It does not tell you what ready means, which part the signal belongs to, who clears it, how long it remains valid, what happens after a restart, or how a failure is recovered.

An interface is a contract between systems:

Meaning → ownership → update rule → validity → timing → recovery → evidence.

1. An I/O list describes wires, not behavior

Documenting addresses and names is necessary, but it does not define sequence. Two stations can both use Ready=1 while one means “powered and safe” and the other means “the carrier is present and the recipe is loaded.” The integration will fail even though every wire is connected.

2. Define the boundary before the signal

State where ownership changes: material, energy, data, permission, command, and result. Define which station owns the carrier, which one owns the process result, and which one can request recovery. A boundary without ownership creates two controllers that both wait for the other.

3. Six minimum properties for every data item

Producer

Which system creates the value and under what condition?

Consumer

Which system may act on it, and what does it do when the value is absent or invalid?

Semantics

What exactly does the value mean, including units, state, polarity, and transaction?

Update rule

When is it set, changed, held, acknowledged, and cleared?

Validity and quality

How are stale, unknown, simulated, or failed values marked?

Recovery ownership

Who diagnoses, resets, retries, cancels, and reconciles the transaction?

4. Separate permission from commitment

Permission means an action is allowed. Commitment means a system has accepted responsibility for a specific transaction. “B is ready” must not be interpreted as “B has accepted carrier 123.” Use separate data or a transaction record so a station cannot start a second part while the first remains unresolved.

5. Do not reuse one bit for command, state, and result

A command requests an action. A state reports what is true. A result reports what happened. Combining all three in one pulse or latch creates ambiguity after a missed scan, reconnect, or restart. Give each a clear owner and lifecycle.

6. Review state machines in composition

Station A can be internally correct and still fail with Station B if their states do not align. Review joint states: waiting, ready, requested, accepted, executing, complete, rejected, cancelled, faulted, and recovering. Write the allowed transitions and invalid combinations.

7. Transaction identity: same event or a new event?

Use a carrier, part, recipe, or transaction ID where a repeated signal could be mistaken for a new item. Define when an ID is created, transferred, acknowledged, completed, rejected, expired, and archived. Do not infer identity from timing alone.

8. Timing contract: timeout is an engineering requirement

Define response time, execution time, heartbeat, timeout, retry count, and escalation. Include worst-case cycle, network latency, operator hold, utility recovery, and downstream blockage. A timeout should produce a meaningful state and recovery instruction, not just an alarm number.

9. Stale data is more dangerous than obvious loss

A missing signal is visible. A signal that remains high from the previous carrier can authorize the wrong action. Add sequence numbers, timestamps, validity, quality, or explicit clear/acknowledge rules. Test delayed, duplicated, out-of-order, and partially updated data.

10. Restart and reconnect need reconciliation

After a power loss or communication reconnect, each station should know whether a transaction was not started, accepted, executing, complete, rejected, or unknown. Reconcile with physical presence, recipe, actuator state, and safe recovery. Do not resume from a bit that happens to be high.

11. Cancel, abort, reject, and fault are different

Cancel is an intentional request to stop before commitment. Abort interrupts an accepted transaction. Reject is a process result. Fault is an abnormal condition requiring diagnosis or safe recovery. Separate meanings so downstream systems know whether to retry, discard, inspect, or escalate.

12. Versioning is part of the interface

Record contract revision, producer and consumer software, data schema, supported features, and compatibility. A new field, changed polarity, unit, timeout, or state name can be a breaking change. Use version negotiation or a controlled rollout rather than changing both stations informally.

13. PackML is a reference pattern, not magic

PackML or ISA-88 patterns can provide shared language for modes and states. They do not define the project’s ownership, transaction, product data, safety, timeout, or recovery by themselves. Adapt the pattern to the actual boundary and verify the composition.

14. Safety and security boundaries

Define which signals are safety-related, which are ordinary control, and which require authenticated or protected communication. Do not use a standard “ready” bit as proof of a safety condition. Protect remote commands, log changes, and make safe behavior explicit when communication is lost.

15. Hypothetical carrier transfer A to B

Short contract

A owns the carrier until B acknowledges the carrier ID. B may request a transfer only when its safe receiving state, recipe, and capacity are valid. B returns accepted, executing, complete, reject, or fault with the same ID.

Failure case

The network reconnects after B accepted the carrier but before A receives the result. Both stations must reconcile ID and physical presence instead of starting a second carrier.

Acceptance evidence

Test normal transfer, wrong recipe, duplicate ID, stale ready, timeout, power loss, reconnect, reject, abort, sensor mismatch, and recovery. Save logs, state traces, and operator instructions.

16. What belongs in an Interface Control Document?

Include boundary, purpose, scope, terminology, data dictionary, producer/consumer, ownership, state and sequence diagrams, transaction ID, timing, timeout, error, retry, cancel, reject, fault, restart, version, safety, security, test cases, evidence, change process, and contact owners.

17. Interface review checklist

[ ] Boundary and ownership are explicit.
[ ] Each item has semantics, producer, consumer, update, validity, and recovery owner.
[ ] Permission, command, state, result, and commitment are separate.
[ ] Transaction identity survives delay, retry, and restart.
[ ] Timing and timeout are measurable requirements.
[ ] Stale, duplicate, invalid, and out-of-order data are handled.
[ ] Cancel, abort, reject, fault, and recovery have distinct meanings.
[ ] Versions and compatibility are controlled.
[ ] Safety and security boundaries are explicit.
[ ] Acceptance tests cover normal, abnormal, reconnect, and recovery behavior.

Conclusion

Station integration is not a collection of bits. It is a contract about meaning, ownership, transaction, timing, validity, failure, and recovery. Design that contract before coding, test it at composition level, and hand over evidence that another team can use at 3 a.m.

18. Observability is part of the contract

Record transaction ID, state, transition, producer, consumer, timestamp, timeout reason, retry, and recovery action. A trace should allow an engineer to answer which station owned the carrier, which condition blocked the transition, and whether the data was valid at that moment. Avoid logging only the final fault; the sequence before the fault is often the evidence.

19. Interface changes need a rehearsal

Before connecting production stations, use a simulator, spare controller, or controlled dry run to exercise normal, delayed, duplicate, missing, stale, and out-of-order messages. Check operator instructions, alarm wording, reset permissions, and rollback. A successful single transfer does not prove that reconnect and recovery are safe.

20. Handover and change control

Protect the Interface Control Document, data dictionary, state diagrams, test traces, version matrix, known deviations, and owner contacts. When one station changes, analyze the contract, update compatibility, test the composition, and record which assets received which revision.

References

IEC 61131-3:2025 — Programmable controllers: https://webstore.iec.ch/en/publication/68532
IEC 61512 — Batch control: https://webstore.iec.ch/en/publication/6030

View all MINATA technical articles