Common industry advice about what good looks like at L0 to L2 is this: “get the foundation right and everything above it inherits that quality; get it wrong, and no amount of dashboarding saves you.”

Salem focuses on one floor up. From our experience, the failures we see at this level look nothing like those at L0. Below L3, bad integration can be derived from a naming problem. For example, a tag called AI_4032 that no one can decode. Above L3, improper integration is typically an ownership problem. These problems are invisible, until they cost money.

Here’s a version of the same reference card for the layers we live in.

Figure 1 — What good looks like at L4, L3, and L2, on the legacy path and the modern path.

L4 — Business planning and logistics

The legacy path.

ERP or warehouse management running on legacy Operating Systems or legacy hardware. Oracle Rdb or RMS flat files underneath. Application logic in COBOL, BASIC, or DCL. Posting happens in a nightly batch window, and integration, to anything else in the building, is a file drop that somebody’s predecessor wrote years ago.

While these systems are old, they are more importantly always correct: they have been reconciled against physical inventory for twenty-five years; and they are the authoritative record. The undocumented rules that make them authoritative live inside the database in triggers and stored procedures as well as form-level validation that no current employee wrote.

The modern path.

SAP S/4HANA, Oracle Fusion, Dynamics 365. REST and OData interfaces, event-driven messaging, inventory that updates in something close to real time. The business rules are configuration rather than code, which means you can read them.

What good looks like at L4, on either path:

• One authoritative record should exist for inventory and for order state. Not a primary and a shadow copy that “usually agree.”
• Every interface is documented as a contract: what data, what direction, what frequency, and what happens on failure.
• Nothing on the plant floor (L2) is written directly on the ERP database (L4). It is written at L3, which can provide a summarized transaction for L4.

L3 — Manufacturing operations

The legacy path.

In some cases, L3 may not exist as a software: scheduling happens on a dry erase board, WIP is tracked on a clipboard, and production reporting is a spool file that prints during the early morning hours and gets keyed into a spreadsheet by the end of day. The spreadsheet becomes the system of record. And to be honest, it has worked for years albeit its frustrations and limitations.

The modern path.

A real MES or MOM layer — Ignition with Sepasoft, AVEVA MES, or similar. Work orders are dispatched down to the line. Confirmations come back automatically. Material and equipment genealogy is captured as production happens, not reconstructed afterward from paperwork.

What good looks like at L3, on either path:

• Order → execution → confirmation is a closed loop. The system that released the work also learns that it finished, without a human retyping anything.
• Every finished unit can be traced to its order, its material lots, and the equipment that made it.
• Downtime and OEE are computed from the same data the operator sees on the screen. Two sources for the same number means two numbers, and then meetings about which one is right.

L3 is also where a modernization program tends to show return first through production analytics.

L2 — Supervisory

The legacy path.

SCADA and HMI hosted on a legacy version of an operating system that stopped receiving patches a decade ago. Point-to-point drivers, one per device family. Tag lists assembled per screen, so the same physical measurement carries three names depending on which operator station you’re standing at. The historian exists, but it has gaps.

The modern path.

A unified SCADA platform with one tag namespace, data exposed via OPC-UA and MQTT, machine state modeled consistently, one historian, clocks synced from a single source.

What good looks like at L2, on either path:

• Tags are named to a standard before anything subscribes to them.
• All data is available through OPC-UA.
• Alarms are historized, not just displayed.

L2 is the hinge. It’s the highest layer that still speaks the language of the process and the lowest layer that speaks the language of the enterprise. When L2 is clean, L3 and L4 have a strong foundation to stand on.

The rule that governs all three

At L0–L2 the governing rule is about names: if you can’t tell what a tag is from its name alone, the name has failed.

At L2–L4, the governing rule is about system ownership:

If a fact lives in two systems and neither one owns it, the integration has failed.

Not “if it lives in two systems” — replication is fine and often necessary. The failure is unowned duplication. For example, on-hand quantity in the ERP and on-hand quantity in the WMS, both updated by different processes, neither designated as authoritative. Order status in the MES and order status in the ERP, drifting apart between batch windows.

This sort of discrepancy is prevented by standard ISA-95 Part 2 — site, area, work center, work unit — plus one thing that gets skipped constantly: order, material lot, and equipment keys that survive the migration. The same identity in the ERP, the MES, and the historian.

You don’t have to replace all three at once

Modernization doesn’t need to happen across the entire stack at once, and it’s the part we’d most want a plant leader to take away.

Replacing L4, L3, and L2 simultaneously is a multi-year, high-risk, all-or-nothing bet, and it requires the business to stand still while it happens. Real programs go one layer at a time, in whatever order the risk and the return justify — sometimes L2 first to get clean data, sometimes L3 first to close the loop, sometimes L4 last because the legacy system is stubbornly, inconveniently reliable.

But sequencing only works if you’ve done one thing first: decide which layer owns each fact before you replace any of them.

Inventory on hand — who owns it? Order status? Machine state? Material genealogy? Write it down. That document is the actual architecture, and it’s more valuable than any diagram of boxes and arrows, because it’s the thing that tells you what a given replacement is allowed to change and what it must preserve.

Salem Automation modernizes the layers above the plant floor for manufacturers running legacy industrial and enterprise systems — OpenVMS and VAX environments, Oracle Rdb databases, custom warehouse management and MES applications. We keep them operating while we modernize them, in that order. If you’re mapping out which layer to take on first, we’re happy to be a second opinion.

KEEP OPERATING.  KEEP MODERNIZING.