Demystifying Edge Solutions in Industrial Automation: When, Why, and How to Use Them

Having worked with industrial data for many years I continue to have conversations with different stakeholders that seem to misunderstand the use-cases and need for “edge solutions.” My goal with this post is to explain where I’ve used them, what role they played, which devices they were, and how they helped solve specific challenges.

It’s very important to remember that my experiences may differ from what you see in your operation and that there are many approaches to any problem. I’ll do my best to highlight some of the nuances as we went through the selection and deployment process.

Brief Intro

As I mentioned above, it's important to have context on the background of whom is delivering any and all information. I've spent over a decade working in medical devices (Procter & Gamble) and Food & Bev (Kraft Heinz, Post Holdings) on the OT side - I've delivered and led projects from troubleshooting PLCs, HMIs, SCADAs, to deploying full facilities and their architecture (networking, servers, distributed SCADA / MES) primarily on Rockwell Automation and Siemens platforms. I've done a lot of data extraction applications into MES solutions - I've gone through the code to understand the systems, process, and built architectures used for optimal data transfers between the plant floor and IT sytems.

The Fundamentals of OT Systems

I try to avoid the assumption that everyone’s on the same page. In this brief overview, I’ll do my best to illustrate the “general” architecture of an OT system.

On the plant floor, you’ll find various filed devices - sensors, motors, valves, solenoids, relays, etc. These devices are the interface between the electrical and mechanical worlds. They’re the ones that “make the system do things.” These devices aren’t “smart” on their own - they generate signals or do something based on a signal sent to them.

The devices which will typically control field devices are PLCs. They’re basically rugged computers that run software which will process the state of inputs (sensors) and actuate outputs (relays, motors, etc.). Without field devices a PLC is nothing but a processing machine. It’s hardware meant to be programmed, process signals, and drive field I/O.

There aren’t many instances in which a single PLC will control the entire operation. Multiple PLCs will be used in different areas. At this point, you’d normally want a system that can help understand how the different systems are performing, be able to synchronize some of the automation, and have an overview screen of what’s going on the entire line, area, plant, etc. This is where a SCADA (Supervisory, Control, and Data Acquisition) solution comes in. In general, a SCADA lives on on-prem servers and has connections to different PLCs. It serves HMIs (Human Machine Interface) to the plant floor, the operating room, etc. these HMIs will send signals to the PLCs to start / stop / adjust certain processes and ingest data from the PLCs to display fault codes, historical charts, etc.

There are many videos with much more depth on these concepts if you’re interested. If anything isn’t clear, feel free to message me, but that’s the 2 minute general overview.

PLC vs Edge Solution

The first question that comes to mind in every conversation that involves “Edge Solutions” is - Can’t we do it on the PLC?

The short answer is YES; everything can be done on a PLC. A PLC is nothing but a robust computer which operates with the same underlying instruction set you’d find in most other programmable systems.

However, the real answer to that question is a lot more nuanced. The current PLC landscape is such that you can accomplish many tasks on a PLC, but it becomes quite difficult, expensive, and troublesome depending on the application / software. In certain instances it’s impossible, in other instances it’s simply unadvisable.

So where do we (or I) draw this line?

Personally, I believe that PLCs are and should be used for control purposes. They’re best at executing code that controls field devices like clockwork. They’re capable of, but not ideal for data management (Ex: running large arrays or databases). They’re capable of complex code, but aren’t ideal for dealing with scalability. They’re capable of compartmentalizing code, but definitely as good as some of the modern programming languages.

In the real world, these decisions aren’t as cut and dry as one may seem. There are certainly other factors at play - which group is executing the project, who will utilize the software solution, what the timeline / budget look like, and which group is going to service the software.

The Story of a PLC Based Batching System

A common need in food & beverage process based plants is to have a batching system. A batching system is basically what allows one to track the recipes (SKUs), the setpoints for different ingredients, and to execute the process requirements of a specific batch. Without such a system, operators are left with paper based solutions to enter how much of each ingredient they need, how long to stir, how long to cook, etc. This approach is prone to errors and batches would fail QA on a regular basis and thus result in $$$ lost for the company.

As the idea of a batching system is introduced, the company has a few options - A. We deploy an off-the-shelf cloud based solution, B. We deploy an off-the-shelf on-prem solution, C. We develop a cloud or on-prem (edge?) solution, D. We develop a on-PLC solution, E. All other options…

Depending on the budget, how fast this needs to be done, and what it will take to deploy, option D becomes viable. For a small batching system, you don’t need to use much memory, you can keep the same HMI / SCADA software, and you can easily add a few screens that would allow the users to retrieve, modify, and create new SKUs for the batches they want to run.

It’s important to note that going this route typically means that you’re going to have a hard time deploying this onto another site, it’s going to take more engineering effort to develop, it’s probably not going to be portable onto a different system, but it’s going to be a lot more cost effective on the hardware / software license side (if you’re using what you already have).

The project I was part of used the following: 1756-L82 ControlLogix PLC, FTView ME (Later migrated to SE), and various field hardware (feeders and flowmeters are the most relevant here) that was interfaced with the PLC.

I learned a few lessons in the few weeks that it took to build this application:

1. Ladder logic wouldn’t be my language of choice for this type of an application. It simply doesn’t lend itself well to array and data manipulation. The instructions are there, but you need to be extremely careful as one wrong move can put you out of bounds and fault out the PLC.

2. I’ve done a lot of previous work on iOS (A different story here...) and FTView ME Rockwell Automation - Designing a screen layout that was less “process” and more data management wasn’t ideal. In the end, it looked good, but it certainly wasn’t the typical screen you’d see on the plant floor, nor was it easy to design to my standards in the editor.

3. As I would have thought, upon deployment, we immediately got requests to deploy this to other lines and plants. We had asked multiple times as to where this was going to go and the answer was always “it will be a system for this line only.” This is obviously a challenge as no time / effort was allocated toward modularizing this software. It’s not easy to extract and re-deploy PLC software…

4. We saved a lot of money. Deploying the simplest software solution on other platforms would have been much more expensive. With the requirements presented in #3 above, I’m not sure what the breakpoint would have been…

The moral of this story was that this should have been an application that runs on the edge with the possibility of expansion onto an on-prem server.

The Apps that “Live on the Edge”

We constantly hear that something should “live on the edge,” but what does this really mean? Why would something live on the edge? As mentioned above, there are good reasons as to why you’d want something to run outside of your PLCs. To that point, what kind of software typically is needed on the plant floor?

Well, it depends…

In the food & beverage industry for example, you need to be compliant with the FDA. For that reason, there’s a lot of data collection systems you’ll see across the floor. These systems log the state of the process and can be presented to the FDA in case of an audit. There’s not much complexity to these systems - they’re generally temperature and level readings of the process logged onto a chart (in most cases, even in 2025, it’s still paper based). In this scenario, you could easily tie into the PLC from an edge solution and store the information on a hard drive, a database, or pass it into the cloud for cold storage. One can argue about digital vs paper based storage, but this isn’t the point of this post…

Vision systems are another great candidate. In many applications, the vision system needs to be fast and make a decision in a split second. In many others, that’s not the case. Vision systems create a lot of “overhead” as images are taken on a regular basis and are often problematic for the network and local storage.

The Story of Troubleshooting Vision Systems

I’ve done quite a bit of work with Cognex Corporation based systems over the years. The biggest lesson I’ve learned is that vision system deployment is more “art” than it is science. In other words, you need to spend quite a bit of time tweaking and adjusting different parameters until you’re satisfied with the results. In the world of vision systems you’re looking to get as close as possible to rejecting every bad part without rejecting any of the good ones. In other words, you’re basically optimizing on detecting a flaw in the part as accurately as possible.

There’s rarely a straightforward process of getting vision systems in place. The reality for me has been such that you need to try out different tools, approaches, and lighting before you get “close enough” and then you can tweak on an actual line. Despite all of that, you still get false positives due to external factors - the system gets dusty over time, ambient light changes, there’s humidity in the air, etc. Long story short, there’s usually no “set it and forget it” system.

To that point, one of the biggest pain points of vision systems is the ability to look into the historical data and to troubleshoot. This activity is no different from the logs you have on any software system - An engineer needs to spend time and analyze why a good part was rejected, or a bad part was let through. At that point, he can make an adjustment.

Edge Solutions can solve a few challenges here:

• The ability to store data / image files is important. A small camera and a high speed network aren’t going to handle hundreds if not thousands of files sent per second. An edge solution can be used as a buffer for thousands of files, and forward those files via non-critical network as traffic allows.

• Asynchronous adjustments are also made via an edge device - you want to run a tight control loop on the system while being able to process some of the information externally and tweaking the parameters based on historical performance. Vision systems typically run a processor, but it’s nowhere nearly as powerful as the one on an edge IPC (Industrial PC) or server.

Data Applications, Data Context, and More Data

I’ve spent multiple years going from manufacturing site to manufacturing site looking at various data driven solutions. I’ve yet to encounter the same program despite the equipment being sold by the same manufacturer for the same process. The point is that a lot of work goes into understanding the process, understanding the business need, and extracting the data necessary to solve or address a specific challenge.

This process inevitably requires an edge device for multiple reasons.

1 - PLCs and Data

If you’ve done any work with PLCs and control systems, you’ll know that they’re not able to store and process large amounts of data. It’s certainly possible to create arrays and buffer the data for a certain period of time, but it’s not ideal. PLCs don’t have a lot of storage, can’t manipulate data easily, and aren’t very robust at displaying or querying the data.

My general advice is that you can implement basic data manipulation and storage on a PLC, but it’s generally not going to be the right approach.

Edge device can run standard software / IT applications that were designed to handle data, manipulate data, forward data, etc.

2 - Data Manipulation

I’ve used “data manipulation” multiple times throughout this post. What is it really…?

Allow me to break it down.

Picture a massive tank which contains a certain liquid - a brewery, milk product, cleaning solution (CIP), raw oil, etc. this tank is usually equipped with a few sensors. At the very least, you’d see a level sensor which is analog, and two upper and lower limit digital sensors. The most basic functionality of this system is to fill up the tank and discharge it. Obviously, storing liquid isn’t everything a tank is good for - some will be used for cooking (ex: heating element), agitating (ex: mixer), fermenting (ex: pressure), or all of the above. These other use cases, and even the basic tank, usually require other sensors and outputs (motor, valves, solenoids, etc.). Each one of those devices are tied to the PLC.

The PLC is going to scan the input for changes. Without getting too deep into the electronics, a voltage is sensed by a digital input and a voltage or current for an analog input (specialty signals are also possible - Ex: RTD).

For the context of data manipulation, picture the analog level sensor pointing down from the top of the tank onto the liquid. Let’s assume that the sensor outputs 0v when the tank is empty and 10v when the tank is full. What’s the actual output of this sensor in a real life environment when the tank is half full and isn’t filling or discharging?

Reading 1 - 5.02341vdc

Reading 2 - 4.93832vdc

Reading 3 - 5.02321vdc

Reading 4 - 5.00465vdc

Reading 5 - 5.08643vdc

Reading 6 - 4.99983vdc

Reading 7 - 5.16343vdc

Reading 8 - 5.02341vdc

Reading 9 - 4.98534vdc

Reading 10 - 5.01312vdc

Why is this happening and why is this important? Well, electronics aren’t “perfect.” The input is going to have some resistance and capacitance on it. Even a fully disconnected input, while floating isn’t going to display a highly accurate reading. The load (the analog sensor in this example) is also exerting a load on the input. Each device is going to be different.

When it comes to our system, we don’t truly care if the tank is at 50.001% or at 49.992% - the human perception of the machine is the same - the tank is “half full.” However, the PLC is constantly being updated as it doesn’t know what this signal means! We’ve not converted into human readable form, so it doesn’t know that we’re reading the level of a tank - it just knows that the voltage level at the input is changing.

What we’ve gotten thus far is raw data, although one could argue that the analog to digital conversion has happened… That’s a tale for another post. Let’s assume that the PLC has the signal in the raw form and it’s updating every scantime (roughly every 4ms). Does the SCADA or MES need to know about the fluctuations of this signal? In this specific instance, I’d argue that it does not. So when should we update it? On change? On a “delta” of a change? Well, the question is - the PLC will control the process based on a setpoint, do you need to know when the liquid goes up by 0.5%, 1%, 10%, or 0.01%? Personally, I’d argue that this is more art than science. However, it does matter in the context of data being sent to another system - do you want to pass a packet every second? Every 100ms? Every 0.1ms?

You can immediately see why sending raw data into a central broker or a database isn’t always a good idea… Using an edge device for aggregating such data and transforming it into manageable form by setting limits and restrictions is an excellent idea before sending it where it needs to go. You’ll save a lot of money on ingress fees if you’re using a cloud solution!

3 - Data Context

As discussed above, an important piece of the puzzle is identifying what the data actually belongs to. The reality of industrial devices is that as they’re tied to a PLC for control purposes, little to no attention is put in place for the higher levels (SCADA, MES, ERP). This typically means that equipment that was commissioned onto the plant floor will require additional engineering effort to have “data extracted from it.” This process basically entails and engineer going through the code, schematics, and P&ID diagrams identifying signals that need to be collected and sent to the other systems.

PLCs aren’t good at adding context. At best, in a Rockwell Automation PLC you can add tags and aliases which will indicate what the signal is. As far as I know, there’s no way to directly export that structure. There are ways of converting and parsing the file which may make the process easier, but usually it’s going to require some manual labor.

Long story short, an edge device is an excellent solution for adding context to your data. Weather it’s passed using MQTT, OPC, or any other protocol, it’s possible to add metadata to the signals being collected and passed to any other systems in the plant.

4 - Data Presentation

In order to use the data, we must be able to visualize the data. Outside of futuristic use cases where AI does all the work, humans must be able to see the data being collected and to some extent transformed into “easy to understand” (varies by plant…) information. There are many visualization tools including those on the plant floor (HMIs). However, an edge solution can host something that looks “a bit more modern.” Many PLC brands have come up with an embedded web accessible portal, but this isn’t the reality for most legacy systems. You can choose to purchase another $5,000 HMI, or you can visualize directly on the edge.

Edge Hardware - The Complete Breakdown

We’ve talked a lot about the benefits of edge solutions, but we haven’t had a discussion about the actual hardware. Let’s do that in this section.

The most basic edge solution on the current market is a Raspberry Pi . I’d argue that a Raspberry Pi can be used for simple proof of concept projects you can then scale onto robust hardware in the industrial setting. So why is the Raspberry Pi Foundation a good candidate to be called an “edge solution?” What are the requirements?

For one, a Raspberry Pi runs a Linux distribution. This means that I can easily install various software, remote into it, have various applications run on the network, and connect to different devices via various protocols.

A Raspberry Pi is a mini-computer - it’s versatile, has a “decent” amount of RAM, has USB ports, and is capable of performing many different tasks with the cores of the processor.

The main drawback of a Raspberry Pi is the fact that it doesn’t do well in hot environments. Without an external enclosure it will usually overheat and fail in a critical application. There’s a solution to this problem! - From heatsinks, to small fans, to clusters of Raspberry Pis, the world is your oyster.

Stepping Up the Hardware

I’ve yet to see a use case where one would absolutely want to deploy software onto the manufacturing floor via Raspberry Pis. In fact, I’ve seen clusters of Raspberry Pis inside of IT racks and always cracked me up… There’s a better way!

Almost every OEM in the manufacturing space will sell what’s called an IPC - Siemens , Phoenix Contact USA , etc. You’ll also find OEM specializing in IPCs and other closely related products - Advantech , OnLogic , etc.

These IPC are rated for industrial applications. They’re rugged and have passive or active cooling which ultimately results in much more robust operating conditions. The reality of electrical panels is that they’re not always well ventilated… And that’s a generous statement. In short, IT server rooms would usually have HVAC systems tied in which means that they’ll maintain a suitable temperatures; this is rarely the case for industrial control panels.

To that point, I advise all of my customers to use properly rated IPCs for manufacturing operations. You can save short term on a non-industrial solution, but the downtime and issues it will cause isn’t worth the cost to upgrade.

There’s also a difference in performance between various IPCs. Generally speaking, your integration partner / consultant (Ex: Joltek) should know what the system requirements are and size the IPC accordingly. You’d also want to consider what the architecture looks like - In some environments, one central edge device per plant is sufficient, for other applications, you’d want multiple or even one per machine. It’s common to see OEMs add a low-end IPC into each machine for various applications - remote access, data collection, visualization, web client, etc.

To conclude, I advice all of my clients to ensure that whichever devices are being deployed onto their floor (by their teams, OEMs, integrators, or otherwise) meet the requirements of the production environment.

Rack Servers

A rack server isn’t as intimidating as one may think. I’ve personally purchased, commissioned, and installed software onto rack mounted servers. They’re nothing more than a computer with a slightly different form factor which is typically suitable for highly scalable environments (datacenters).

If you’re looking to deploy software which requires this type of hardware, I highly recommend thinking about the deployment strategy. These servers would typically require either a room, or at the very least a cabinet. To that point, if you’re going to deploy the server in a standalone cabinet, put some thought into the location. I’ve often seen these neglected over the years which led to premature failure. With good attention and care, rack mounted servers should last for years, if not decades.

Personally, I've done most of my work on Dell Technologies and Hewlett Packard Enterprise servers, but at the end of the day, the hardware isn't critical as they can be easily swapped out for whatever you prefer. If you're looking to spend some time learning or architecting here, I'd highly recommend getting your hands on a 2-3 generation old server and loading Proxmox Server Solutions onto it. I've got one in my office and I use it for a variety of testing and production solutions.

Edge PLCs

I’ve certainly had to use PLCs as data concentrators which in my mind makes them an edge solution. A dedicated PLC can be used to collect, buffer, manipulate, and pass the data to a server. The reason for doing so is simple - generally speaking, PLCs of the same brand as the others will easily integrate following standard protocols to other devices. I’ve worked on multiple plants in which you’d see an array of Allen Bradley hardware (MicroLogix, CompactLogix, and ControlLogix) that would easily pass data into a standalone ControlLogix before it goes to a server, a SCADA, an MES, etc.

As I mentioned previously, many providers / OEMs have designed PLCs that either run an OS for the control side, or have a separate PCB for that purpose. I’d proceed with caution - An improper deployment can lead to issues. I’d work with a systems architect to determine the use case and to figure out if the PLC is suitable for both control and edge processing. Personally, I am a fan of what Opto 22 has done with their Groov EPIC and an emphasis on cybersecurity and various tools you’d typically see only on the IT side. In this instance, it’s important to find an OEM that understands the value they can provide beyond a bare installation of Linux.

Edge Software

An Edge device is usually a Linux or Windows based machine (Personally, I’d avoid Windows like the plague, but that’s not the reality of industrial applications, so…). In the “larger” instances, one should consider a hypervisor such as Proxmox, Windows Server, etc. This allows one to deploy virtual machines that can be accessed independently, segmented from different networks, etc. The goal here isn’t to go into all details, but in short, you should have a clear understanding of what your partner / systems integrator / consultant is deploying onto your floor and how it’s going to impact production.

When it comes to applications that “live on the edge,” as discussed previously, the world if your oyster. However, it’s important to note that “with power comes great responsibility.” You can install any and all types of applications onto this hardware, but it doesn’t necessarily mean you should. From an IT standpoint, you’re immediately opening yourself up to a host of other issues - firewalls, networking, cybersecurity, patches, etc.

Conclusion

Edge solutions definitely have their place in industrial automation and if you’ve spent time developing applications that access plant floor data in any shape or form, you’ve had to deploy them. They range from on-PLC, through IPCs of different sizes, to rack mounted servers. There’s no clear definition of what an “edge solution” is, but there’s certainly not a lack of misunderstanding as to what they typically should be used for.

My general recommendation is to set clear expectations, understand the requirements, and plan for further expansion.

If you’re looking at a future solution, if you’re in the process of deploying a solution, or if you’re simply having issues with your current deployment, don’t hesitate to reach out!

Other Considerations

Happy to have any and all conversations around this topic. I've certainly experienced and witnessed a lot of different approaches when it comes to IT / OT architectures, but there's always something to learn. Happy to hear your thoughts on the topic! - Leave me a comment below, or send me a DM.