Packaging Machinery

How does OPC UA and PackML engagement for packaging machinery work?

We build the OPC UA and PackML state and data layer inside packaging machinery.

This is for the OEMs and line integrators. You keep the machine, the brand and the end customer; we take the parts that need a standing specialism:

• PackML state and mode models over OPC UA, implemented consistently across the machines of a line
• machine-to-MES interfaces, including companion-spec information models
• the gateway and sensor I/O layer beneath both, aggregating dense low-level streams onto a fixed cycle
• purpose-built nodes and gateways, developed from board bring-up and stack port upward
• migration off CANopen or an older fieldbus onto real-time Ethernet, carrying the machine’s behaviour across
• training your engineers on PackML, OPC UA or the network stack, building the first implementation with them, then third-line support behind their first line

We do not install or commission lines on a plant floor. Where the work has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. The engagement page sets out the modes and how they are priced.

Why does a line need one consistent state model instead of better reporting?

Inconsistency compounds across a line whose machines have no shared state model.

Three builders’ machines and three ideas of what “running” means, where a plant typically prefers one OEE number. Every report above the line then has to reconstruct what happened instead of just consuming the logs, and reconstructions go wrong in critical cases, when two machines change state within the same second. A shared state model solves this without increasingly complex reporting mechanisms, and it is targeted engineering that a machine programme needs once in a few years. The same is true of the layer underneath it: a gateway which has to 2 ms cycle across several thousand points, or a network migration off a fieldbus the machine has run on for a decade.

Which slices of the work can you support?

Any one of the machine's layers: the state model, the MES interface, the IO gateway, the network.

• A machine using PackML. The state and mode model implemented over the existing control logic, without rewriting the sequence.
• Several builders, one line. The same model applied across machines that were never specified together, so the line reports as one.
• A machine-to-MES interface. OPC UA and companion-spec information modelling, on the machine side or the integration side.
• Sensor I/O outgrowing the controller. Dense low-level streams aggregated at a gateway and published on a fixed cycle.
• A device to build. It does not exist yet. A purpose-built node or gateway, built from board bring-up upward.
• A fieldbus that has to be migrated. CANopen or an older fieldbus onto real-time Ethernet, with the machine’s behaviour carried across.
• Team bring-up. Your own engineers brought up to speed. Training, then building the first implementation alongside your team.

What does a shared state model change on the line?

A stoppage has an owner the moment it happens.

When every machine exposes the same states and modes (drawn in the figure under the engagement section), the line reports which machine changed state first and why, instead of an operator reconstructing it afterwards. That also makes line-level logic simpler, because starve and block conditions become readable machine states instead of heuristics built on sensor timing.

How is dense per-machine sensor I/O gathered without losing determinism?

We aggregate the sensor streams at the gateway and publish them on a fixed cycle.

The number of sensor streams, not the control loop, is now what sets the load. Many low-level serial and I2C sensor streams are collected on the device, timestamped locally and published upward on a fixed cycle, so the controller sees one bounded, predictable input per cycle. That structure is what let a delivered machine hold a 2 ms cycle across several thousand points without the aggregation becoming the bottleneck.

What does a custom node at this layer look like?

A custom node is purpose-built, and usually one of two types: a device node or a gateway.

As an example, our team built both for one packaging machine builder, often deployed on the same floor but doing different jobs:

• A real-time Ethernet node bridging down to UART and I2C for sensor and actuator control on a 2 ms cycle, delivered as a migration from CANopen. The machine kept its behaviour and changed its network.
• A gateway that is a slave on one network and master of a sub-hierarchy beneath it, used for conveyor and motion control. That one is covered on the material handling page, since conveyor control is its main use.

Both are OEM product work. The builder’s machines and their customers are theirs; we build the node.

How do you stop a format changeover becoming an engineering job?

Changeover cost is decided at design time, long before the format changes.

It is set by how the machine’s format parameters and state handling were structured in the first place. We keep format-dependent values as parameters against a fixed state model, so a new SKU is a data change and a validation pass rather than new sequence logic. Because the states are standard, the MES can then drive and record the changeover instead of watching it happen.

What does the PackML state model specify for the machine?

A fixed vocabulary, and the legal moves between its terms.

The states include Idle, Starting, Execute, Holding, Suspending, Stopping, Aborting, Completing, Resetting and Clearing, and the value is that they mean the same thing on every machine that implements them. “Holding” on the filler and “Holding” on the case packer describe the same condition, so a line controller and an MES can reason about both without a translation table per supplier. The transitions are as important as the names. Because the legal moves are defined, a line can be interlocked on states instead of ad-hoc signals, and a machine added later into the line inherits the same contract without needing its own sequence logic.