What the classic stack is actually struggling with

The PLC/DCS layer does far more than control, and that is the problem. Control programs are written for safety and determinism, and rightly so. But look inside a typical PLC or DCS program today, and you will find a surprising amount of business logic that exists only to serve the MES integration: how process messages are constructed for different cases, how different recipe formats are received and parsed, and other routines only distantly related to the automation system’s main task of controlling actuators, sensors, and motors. Every change to this logic means modifying a validated control program, which is slow, expensive, and risky, so in practice it’s made only when absolutely necessary. The same logic, placed in a DataOps layer above the controllers, is far easier to maintain, and adding a new message format or recipe variant becomes a configuration task instead of a PLC project.

The Historian collects large amounts of raw data, and much of it is never used or required by any regulation. The bigger problem, though, is what it takes to make that data useful. Turning raw tags into information requires information modeling, and here the classic stack makes you do the work twice. The Historian is seldom the source of present values, so the MES cannot rely on the Historian’s structures and builds its own model of the very same plant. The result is two heavily overlapping modeling efforts on the same layer of the architecture, neither benefiting the other, both maintained separately as the plant evolves. Placing an Industrial DataOps layer in front of a local time-series database instead is a combination that performs most of the tasks of both the Historian and the MES data collection at a fraction of the cost, and a single information model in Industrial DataOps serves both applications. Anything new is built as an extra on top of the same model, but no parallel models requiring custom linkages are required anymore.

The old-style on-premises Historian does not fit that well with modern data analysis. Modern analytics requires all relevant data in one place: production data alongside purchasing, sales, logistics, and warehouse data. A site-local archive in a proprietary format is exactly the opposite of that, which is where cloud data storage comes into play. The trend is recognized even by established historical vendors, which are offering cloud-based variants of their old systems, and new start-ups and early-stage companies are basing their cloud solutions on InfluxDB, a PostgreSQL variant, TimescaleDB, and other time-series databases, each with their own modifications.

And finally, MES products have never been particularly strong in connectivity. Their strength is orchestrating production, not talking to dozens of different device types. In older installations, integrating the various data sources has typically been done through customization or custom-made connectors built during the project and rarely touched afterward. How many cases have I seen with a middleware database as the integration point between the MES and actual production, with dozens of back-and-forth connectors, and these customizations aging badly. The developers who built them leave, the hidden knowledge disappears with them, and ten years later nobody dares to touch the interface that keeps production running. The better way to do this is to connect MES to the Industrial DataOps layer via OPC UA and let DataOps handle connectivity. It’s meant to do that in an easily maintained and configurable way without the need for custom coding.