When a serialization project is drawn on a whiteboard, it is tempting to connect the coder straight to the ERP or to a cloud platform. On paper, that is simpler. On a line running at 120 packs a minute, it is a recipe for stoppages. This guide explains why serialized lines need a local software layer, often called edge software or a line gateway, and what that layer should do.
The timing problem
A packaging line runs to a beat. At 120 packs a minute, a new pack reaches the coder every half-second. In that window, the line must choose a serial, send it to the coder, print it, read it back, compare it and, if needed, trigger a reject.
Networks and enterprise systems do not run to a beat. An ERP might answer in 50 milliseconds most of the time and in four seconds during a month-end report. A cloud service can be briefly unreachable while a router restarts. Neither is a fault, exactly — it is simply how shared systems behave.
If every pack needed a live answer from the ERP or cloud, every hiccup upstream would become a missed print or a line stop downstream.
Think of a restaurant kitchen. Chefs do not phone the supplier for each portion of rice. They keep stock in the kitchen, cook from it at service speed, and reorder in the background. Edge software is the kitchen stock and the kitchen manager.
What "edge" means here
"Edge" simply means close to where the physical work happens — on the factory network, near the coders and cameras — as opposed to a data centre or the cloud. Edge software for serialization typically runs on an industrial PC or local server and talks to:
- downward: coders, cameras or barcode readers, reject devices (often via the line's PLC), label printers and packing stations;
- upward: the ERP or serialization system, and any cloud platforms.
It sits in the middle, translating between the line's beat and the enterprise's pace.
What the edge layer should do
Hold a local pool of serials
Before or during a run, the edge layer fetches serials from the ERP in blocks and stores them locally. The line then draws from this pool without waiting on anything upstream. We describe how serials get there in what happens after an ERP creates a serial number.
Run the time-critical loop locally
Sending serials to the coder, matching camera reads to the expected serial, deciding on rejects and tracking which packs go into which carton all happen locally. That carton record is the start of the hierarchy described in how individual products become cartons and pallets. None of these steps should wait for a network response.
Keep durable local records
Every serial's status — sent, verified, rejected, packed — and every carton's contents are written to local storage that survives a power cut or restart. If the PC reboots mid-shift, the line software must know exactly where it was, rather than guessing.
Queue results for upstream systems
Results bound for the ERP (which serials were packed, in which cartons) or the cloud (supply-chain events) go into a persistent outbox — a local queue written to disk before sending. Delivery happens in the background. If the destination is unavailable, the queue waits and retries; it does not block the line. Events may later be expressed in standard formats such as EPCIS for sharing with trading partners — see what EPCIS is.
Recover cleanly
When something is uncertain — a message sent but no reply received — the edge layer checks the destination's current state before resending, so nothing is registered twice. This is central to exactly-once serialization.
What the edge layer should not do
Clear boundaries matter as much as capabilities.
- It should not replace the ERP. The ERP remains the authority for products, orders and — where it issues them — serial values. The edge layer executes line-side work and reports back.
- It should not invent identities silently. If serials run out, it should stop or alert, not generate numbers outside the allocated range.
- It should not overrule safety systems. Machine safety and interlocks belong to the line's own control systems.
- It should not pretend to know more than its devices tell it. A printer acknowledgement is recorded as an acknowledgement, not as a verified code.
The full split of responsibilities is laid out in how ERP, printer, scanner and packaging line work together.
Example: a network outage on Line 3
At 14:10, the router serving Maison Ardent's fictional Line 3 restarts after a firmware update and the plant loses its ERP connection for twelve minutes.
On the line, nothing visible happens. The edge software has 6,000 serials in its local pool, enough for roughly fifty minutes at 120 a minute. Printing, camera checks, rejects and carton packing continue from local data. Completed cartons are written to the outbox.
When the connection returns at 14:22, the outbox delivers the backlog. For one carton whose registration was sent just as the link dropped, the edge software asks the ERP whether it was received before deciding whether to resend. The supervisor's dashboard showed the growing backlog throughout, so nobody was surprised.
Had the outage lasted longer than the agreed window, or the pool run low, the software would have warned the supervisor and then stopped the line in a controlled way. What happens in those cases is covered in what happens when the internet or ERP goes down during production.
Questions to ask about any edge design
- How many serials does the local pool hold, and how long does that last at full speed?
- What happens to in-flight data if the PC loses power?
- How is an uncertain upstream delivery resolved?
- Who is alerted when the outbox grows, and at what threshold?
- What is the agreed maximum offline window, and what happens at its end?
- How are software updates, backups and access control handled on site?
If a design cannot answer these, it is not yet ready for a production line. The station-by-station view of where edge software sits is in the journey of a serialized product through a packaging line.