Fleet management

Five buses. One machine.

A real cell rarely speaks one language. The drive is on EtherCAT, the manifold answers Modbus, the robot exposes OPC UA nodes, the scanner sends a serial packet, and the vision system opens a socket and pushes bytes at you.

Supporting all five is the easy half. The half that decides whether the project stays maintainable is what happens to those values after the connection is made.

A mixed-protocol cell: the StateTick runtime at the centre terminating five buses at once. EtherCAT to a coupler carrying a conveyor drive and product sensors, Modbus TCP to remote I/O on a pneumatic manifold, OPC UA to a robot cell controller, serial to a barcode scanner head, and raw TCP/IP to a vision gateway. Each link is labelled with its raw address and the machine alias it becomes. — One runtime, five buses, one machine model. Every link carries a raw address on the wire and a machine name into the logic.

The argument in four steps

01 Addresses are not variables Every bus describes data differently. None of those descriptions belong in your logic. 02 The alias layer One name per thing, mapped once, used everywhere. 03 The state machine coordinates Five protocols, one sequence, written as if the machine were one device. 04 Hardware becomes swappable Change the bus under a name and the behaviour above it does not move.

Every bus describes data differently

And none of those descriptions is about your machine.

An EtherCAT input arrives at a process-data offset. A Modbus value sits in a holding register. An OPC UA server exposes a node with a namespace index and an identifier. A serial device answers with a field inside a response frame. Four devices, four vocabularies, none of which mentions what the value is.

Write logic directly against them and the logic inherits the vocabulary:

IF HR40012 > 6.0
   AND EtherCAT1.InputByte3.Bit2
   AND OPCUA.ns3.RobotReady
THEN ...

That condition is correct and almost unreadable. It describes an installation, not a machine. Six months later the person maintaining it has to reconstruct three separate addressing schemes before they can answer a question as simple as why did the clamp not close?

And it is brittle in a specific, expensive way: move the transmitter to a different register and the sentence about machine behaviour has to be edited, even though the machine's behaviour did not change.

The alias layer

Map it once, where the wiring is described. Never again anywhere else.

Every configured address on every bus gets a name. The driver still knows the offset, the register, the node, the frame field — that is its job. Nothing above it does.

EtherCAT   InputWord.4              →  Conveyor.SpeedFeedback
Modbus TCP Holding Register 40012    →  Tank.Pressure
OPC UA     ns=3;s=Status.Ready       →  Robot.Ready
Serial     Response.Code             →  Product.Barcode

The same condition, written against names:

IF Tank.Pressure > 6.0
   AND ProductSensor.Detected
   AND Robot.Ready
THEN ...

Identical behaviour. The difference is that this one states intent, and a person can read it without first learning your I/O map.

It also moves the blast radius of a hardware change. Re-address the pressure transmitter and you edit one mapping. Tank.Pressure still means what it always meant, so every state, condition and interlock that used it is untouched — including the ones you had forgotten about, which are the ones that break.

The three layers in full. Layer 01, physical and communication: five devices, each labelled with the bus it speaks - serial, OPC UA, raw TCP/IP, Modbus TCP and EtherCAT. Layer 02, address and alias: one card per device showing the raw address and the machine alias it becomes, such as Holding Register 40012 becoming Tank.Pressure. Layer 03, the state machine: a cycle of five states from WAIT_FOR_PRODUCT to VISION_CHECK, each reading and writing aliases only. — Three questions, three layers, answered once each — *where does this value come from*, *what does it mean*, *what should the machine do with it*. Only the bottom layer knows a fieldbus exists.

The state machine coordinates

Aliases decide how a device is represented. This decides how the devices work together.

Take a cell with a conveyor on EtherCAT, a pneumatic manifold on Modbus TCP, a robot on OPC UA, a barcode head on serial, and a vision gateway pushing raw TCP. Five buses, five sets of failure modes, five ways of describing a boolean.

Once every signal has a name, the sequence reads as one machine:

WAIT_FOR_PRODUCT   →  ProductSensor.Detected
READ_PRODUCT       →  Product.Barcode
POSITION           →  Conveyor.Run, then Conveyor.AtPosition
ROBOT_PICK         →  Robot.Start, Robot.Busy, Robot.Complete
INSPECT            →  Vision.Pass  →  else RejectValve.Activate

Underneath, those six names are carried by four different protocols. The sequence does not say so anywhere, and that is the point: it coordinates machine functions, not transports.

One runtime terminating all five buses. Each link carries a raw address on the wire and a machine name into the logic; only the runtime ever sees both.

Hardware becomes swappable

The reason this matters commercially, rather than only aesthetically.

Two builds of the same machine. One customer standardises on EtherCAT remote I/O; the next has a plant full of Modbus and no intention of changing. Both machines still need to know whether the clamp is closed and whether the product is there.

Expose the same four names from both — Clamp.Closed, Clamp.OpenCommand, ProductSensor.Detected, Motor.Run — and the state machines are very nearly identical across the two builds. What differs is a mapping table, which is the cheapest thing in the project to change and the easiest to review.

For a machine builder supporting several hardware configurations, that is the difference between maintaining one machine with several I/O maps and maintaining several machines that happen to resemble each other.

Protocol support on its own is a checkbox. Nearly everything in this market claims it. What decides whether the fifth variant of a machine takes a week or a quarter is whether the fieldbus ever reached the logic in the first place.

Hardware & protocols covers which transports the runtime speaks and what it runs on. Machine architecture is about structuring the variable space itself, which is what makes a name like Tank.Pressure possible.