Most people in industrial automation still believe that hardware is inherently more reliable than software. But many of the assumptions behind that belief were formed decades ago, before connected operations, edge computing, and software-defined industrial systems became a reality. In this article, we challenge five of the most common myths about software in industrial environments.
Most people in industrial automation still believe that hardware is inherently more reliable than software. But many of the assumptions behind that belief were formed decades ago, before connected operations, edge computing, and software-defined industrial systems became a reality. In this article, we challenge five of the most common myths about software in industrial environments.
Hardware is more reliable than software.
Everyone knows that, right?
It's one of those unquestionable truths that gets repeated in discussions over and over again.
Dedicated hardware is safer. Software is fragile. End of debate.
Or... is it?
What if I told you some of the assumptions behind this belief are no longer true? Would you call me crazy?
Then keep reading...
Let's start with probably the most emotional argument in the debate: the attachment to the PLC. OT professionals have spent entire careers next to these machines. They can touch them, open the cabinet, see the lights blinking. PLCs feel real. Software, on the other hand, feels abstract. Almost like a ghost hiding in the dark, doing things you can't see.
And yes, a PLC sitting in a cabinet for twenty years without being touched will probably keep running. I won't argue with that. But the real question here is...
"Is that enough?"
What was once considered an asset is slowly becoming a liability. Limited remote diagnostics, difficult integration with modern systems, and little visibility into what is actually happening. You're not really managing it. You're just watching it do its thing.
Now, if you look at the alternatives, soft PLCs based on IEC 61131-3, and newer IEC 61499-based automation platforms (probably the two most relevant standards in this space) offer a familiar programming model, but decouple the application from a specific piece of hardware. They can run on standard computing platforms, integrate natively with IT systems, be monitored remotely, and evolve without requiring hardware replacement. In this model, the application becomes the primary asset, not the box it runs on. Arguably, this is how it should have been all along.
Most importantly, software-defined control systems introduce something that traditional PLC architectures have always struggled to provide: observability. You can monitor performance in real time, detect anomalies before they become failures, and intervene proactively.
Detecting a failure is useful. Predicting and preventing it is something else entirely.
This one sounds very technical. And that's exactly why it's so effective at shutting down conversations. Drop "deterministic latency" or "real-time response" in a room full of engineers and watch the rest of the people go quiet, staring into the infinite.
But let's unpack it.
Yes, a dedicated PLC or FPGA running on bare metal can deliver extremely predictable timing. But here's the question nobody asks:
"Does your application actually need microsecond-level determinism?"
Because the vast majority of industrial processes — from HVAC to water treatment to discrete manufacturing — operate on cycles measured in milliseconds or even seconds. The determinism argument is technically valid for a narrow set of applications, but it is wildly overapplied.
Now, let's imagine your application really does require hard real-time performance. Let's imagine your production line is that special. Software still has an answer for you: Real-Time Operating Systems (RTOS). Systems such as VxWorks or QNX, and real-time Linux kernels with PREEMPT-RT patches deliver deterministic performance while running on standard industrial PCs.
These technologies are not experimental. They have been used for decades in aerospace and other environments where timing failures are simply unacceptable.
For me, the real question here is not "Is software faster?"
The real question is:
"Is it fast enough for my application?"
And in most industrial use cases, the answer is yes.
This one has a certain seductive logic to it. What you can't reach, you can't hack. Air-gapped systems, no network connectivity, no exposure.
Except it's not 2005 anymore.
The uncomfortable truth about modern industrial environments is that the air gap is already gone for most facilities. Industry 4.0, IIoT, remote monitoring, OEE dashboards, ERP integrations... every one of these initiatives punched a hole in the wall. The hardware is connected now, whether you know it or not. And connected hardware running decades-old firmware is not a cybersecurity strategy. It's a ticking clock.
Software-defined systems, by contrast, are designed for a connected world. They come with role-based access control, encrypted communications, audit trails, automatic monitoring and —most importantly— rapid patching. When a vulnerability is discovered, you push an update. Systematically and at scale.
When firmware on a proprietary PLC has a vulnerability, you call the vendor, wait a few months, and then physically visit every cabinet in your plant.
Good luck with that.
The most dangerous device in your plant is not the one running software. It's the one running firmware from 2008 that nobody remembers how to update.
This is the CFO argument. The spreadsheet says the hardware was purchased fifteen years ago, it's fully depreciated, and it's still running.
Case closed.
But let's talk about software licensing honestly. Yes, software comes with recurring costs. But what do you get in return? Continuous improvement, new features, security patches, support and compatibility with evolving systems. The platform keeps moving forward. The alternative is a hardware asset that appears inexpensive only because nobody is accounting for the cost of maintaining it.
If we think in terms of Total Cost of Ownership, the conversation looks completely different. A software update can be deployed to 50 sites simultaneously, while a hardware upgrade often requires 50 separate maintenance windows, 50 travel expenses, and 50 opportunities for human error.
And the commoditization of hardware is accelerating this shift. Software-defined systems run on standard industrial PCs and edge devices that you can get from multiple vendors, replace in hours, and scale without lengthy procurement cycles.
The hardware becomes replaceable. The application becomes the asset.
We've already seen this transformation in industrial software. Look at what Inductive Automation did to the SCADA market with Ignition. Traditional SCADA platforms often relied on licensing models tied to tags, clients, servers, or combinations of these. Ignition shifted this model toward a software-defined platform approach: unlimited tags and clients, with licensing based on the server runtime rather than system scale.
The hardware isn't cheap. You've just been paying for it in ways you didn't even know.
You see the red LED, you know what failed. I get it. There's something deeply satisfying about a physical indicator that tells you exactly what's wrong. No log files, no SSH sessions... Just a red light.
But let's be honest about what that red light means: something has already failed. You're not maintaining the system. You're reacting to it. And in an industrial environment, reactive maintenance means downtime, and downtime means money.
Software-defined systems don't wait for the red light. They give you continuous telemetry: CPU load, memory usage, communication latency, error rates... all streamed in real time to a dashboard. You don't find out the system failed. You find out it's about to fail, and you fix it before production is affected. That's not just better maintenance. It's a completely different operating model.
Now let's talk about the update argument, because this is where the hardware defenders have a point — or used to. Yes, updating software used to mean downtime. But edge computing changes the equation. Modern edge architectures run on highly available nodes where workloads can failover in seconds. You update one node while the other keeps the process running. You validate, then switch. Zero unplanned downtime.
And once edge infrastructure enters the picture, another advantage emerges: scale. A software-defined operation can be monitored and updated across dozens of sites from a central location. Compare that with the traditional model: a field engineer carrying a laptop and a proprietary programming cable, from site to site, opening cabinets and applying changes manually.
That model doesn't scale. It never did. We simply accepted it because there was no practical alternative. Now there is.
We've covered five myths today. Five arguments that have been used for years to justify keeping software out of industrial control systems. And while each of them contains a grain of truth, none of them tells the whole story anymore.
Hardware is not more reliable — it's just more familiar. Not faster — only faster where most processes don't need it. Not more secure — just less visible, which is a very different thing. Not cheaper — just better at hiding its costs. And not easier to maintain — just easier to react to after something has already gone wrong.
"Ultimately, this is not a debate about hardware versus software. It's a debate about adaptability."
Hardware was optimized for a world that changed slowly. Software is optimized for a world that changes continuously. And industrial systems are changing faster than most people in the industry are willing to admit.
The most dangerous thing in your plant is not a piece of software. It's a cabinet nobody dares to touch.
Barbara enables industrial organizations to deploy, orchestrate, and continuously manage distributed applications and AI models directly at the edge — where latency, bandwidth constraints, and data sovereignty cannot be compromised.
Built for complex environments with SCADA systems, PLCs, legacy protocols, and heterogeneous hardware, Barbara helps IT and OT teams move beyond pilots and scale secure edge deployments to thousands of nodes.
If you're working on similar challenges or exploring how edge platforms can support your industrial initiatives, explore more insights on our blog or get in touch with our team to continue the conversation.
Alternatively, you can also start using the platform today.