Recommendations for Managing Fragmented Automation Systems At Small Manufacturers

Here’s an email from a knowledgeable customer with a problem that so many small manufacturers experience every day:

What this customer is really asking is, “Is there a better way to structure how different automation systems work together across a factory?”

As an operations or control engineer, it’s incredibly hard to understand what to do given the new technologies, the different architectures being proposed, the new standards being introduced by trade organizations and the general noise from the posters on LinkedIn. It’s hard for me to do and my job is to monitor all of this.

My message is to stop connecting applications to machines and start connecting applications to standardized representations of the factory floor. For a small manufacturer facing this challenge (that’s just about all of them), this is what I would recommend:

Separate Machine Connectivity from Your Applications

This is the most important recommendation in all my years of writing about Smart Manufacturing. Do not let any of your MES systems, dashboards, AI tools, reporting systems or maintenance applications connect directly to PLCs and machine control devices.

What the Collaborative Ecosystems for Smart Manufacturing Innovation Institute (CESMII) recommends – and I strongly agree – is to build a data/interoperability layer. That layer normalizes, scales and models data in your control network, and makes it available using open, standardized IT-like interfaces. Your applications should only consume organized, normalized and meaningful information, not raw data.

Define Data Models That Focus on Manufacturing Priorities

Define data models that enhance the operation of your manufacturing production systems. That’s not hard to do if you start with the end in mind. Begin by defining the problems to be solved, the data elements required to solve them and building those data elements into data models.

For example, if quality is an issue, what questions do you have on quality? What data from what devices do you need to answer those questions? You’ll likely want to build a quality data model, a predictive maintenance model and other models specific to your process. Start today.

Standardize the Meaning of Data, Not Just the Data Format

Getting a temperature value from five machines is not useful if each machine names it differently, uses different units or provides different context. Define common equipment, process, product, state, alarm and production concepts. This is essentially the problem Smart Manufacturing Profiles (as defined by CESMII) are intended to solve.

Demand Standardized Application Interfaces

Require your Interoperability system suppliers to demonstrate how any outside application can access the equipment models, instances, relationships, current values, history, alarms and events of your control system. Your goal should be to have a single standard interface instead of learning a proprietary API or customizing a standard protocol with a vendor-specific custom payload. That is the specific problem that CESMII’s i3X interoperability standard addresses.

Build Data Models that Model Relationships, Not Just Collect Tag Data

Knowing a temperature value of 178°F is much less useful than knowing that it is the discharge temperature of Compressor 3 on Line 2 building Product Y147. Your interoperability layer should build the unifying relationships between all the devices in your production control system.

Plan for a Variety of IT Application Interfaces

You’ll want an API standard (i3X) for standardizing how applications read, write and query data, data types, metadata and history. You’ll also want a lightweight publish/subscribe transport protocol (MQTT) for moving real time event data to databases and applications. Both are necessary.

Design for Applications You Haven’t Bought Yet

The biggest architectural mistake is optimizing the factory data architecture around today’s dashboard or MES. Build an information layer that lets tomorrow’s maintenance system, quality application, energy management package, analytics software or AI agent consume the same standardized information without rebuilding the factory integration layer.

Require Historical Data to Use the Same Model as Real-Time Data

Do not build one architecture for current values and another completely different architecture for history. Ideally, an application should be able to find a machine, understand what it is, retrieve its current state and query its historical state through the same information structure. CESMII includes current and historical objects as part of the platform requirement.

Use an Interoperability Layer That Supports Reusable Machine Types

If you have six similar CNC machines, do not model six unrelated machines. Create a CNC machine type and instantiate it six times. Do the same for presses, robots, ovens, fillers, compressors and other repeated assets. Your interoperability layer is the layer that should pull these standardized data models from your repository and instantiate them in a production system instance.

Start Small, Prove the Value, Then Scale

You don’t have to model the entire factory before you get value. Pick one line or one pressing question, stand up your interoperability layer there and show a win. Once the pattern works, instantiate it across the rest of your machines and lines. The reusable models you built in points 5 and 9 are what make scaling the second, third and fourth line dramatically easier than the first.

BONUS: Don’t Build the Interoperability Layer Yourself

Small manufacturers rarely have the staff to build and maintain custom middleware, and the “few scripts” approach is exactly what got you fragmented in the first place. Buy an embedded, standards-based layer that already speaks your protocols, normalizes your tags and models your data, so your team spends its time solving manufacturing problems instead of maintaining integration code.

The RTA Historian

Manufacturers that want to begin by starting small with a standards-based layer should consider the lightweight, embedded RTA Historian from Real Time Automation. This product supports numerous protocol interfaces on the machine, normalizes tag data and supports extensive data modeling. It is a perfect, low-cost, easy-to-use product to begin separating your connectivity from your applications.

Learn more about the Historian, email solutions@rtautomation.com or call and speak to an Enginerd at 262-436-9299.