Daniel sent us this one — he's been thinking about PLCs again, which we've touched on before. The question is about what's actually running on these things at the operating system level. Are we talking bare-metal execution, like an ESP32 where the code runs right on the hardware with guaranteed timing and nothing between you and the metal? Or is there a real kernel in there, with layers, a scheduler, maybe even something that looks vaguely like the stacks we know from user-facing computing? And he's right that Siemens dominates the landscape, so that's our natural starting point. It's a deceptively simple question that opens up a whole world.
It really does. And the answer is — it's both, depending on where you look, and the history of how we got here is genuinely fascinating. Let me start with the Siemens lineup because that's what most people encounter. The S7-300 and S7-400 series, which have been the workhorses of industrial automation for decades — those run a proprietary real-time operating system developed entirely in-house by Siemens. It's not VxWorks, it's not QNX, it's not anything you can buy off the shelf. Siemens calls it the S7 firmware, and it's a closed, tightly integrated stack that handles everything from the scan cycle execution to the communication processors. But here's where it gets interesting — the newer S7-1200 and S7-1500 controllers, which have been rolling out over the last decade or so, they actually shifted to a different foundation.
Shifted to what?
This is one of those details that doesn't get talked about much outside of industrial security circles, but the S7-1200 and S7-1500 run on a real-time operating system called Nucleus. It's made by a company called Mentor Graphics, which is now part of Siemens actually — Siemens acquired Mentor back in 2017. So in a roundabout way, Siemens bought the company that makes the operating system their newer PLCs run on. Nucleus is a proper RTOS. It has a kernel, it has a scheduler, it manages memory, it handles inter-process communication. It's not a general-purpose OS like Linux or Windows, but it's absolutely a real operating system with layers and abstractions.
The newer ones are actually more complex under the hood than the older ones. That feels counterintuitive — you'd think the trend would be toward stripping things down.
You'd think. But the reality is that modern PLCs are being asked to do things that the old S7-300 and S7-400 firmware was never designed for. Motion control, integrated safety, web servers for diagnostics, OPC UA connectivity, Ethernet-based fieldbus protocols like PROFINET with isochronous real-time requirements. The S7-1500 in particular is basically an industrial computer that happens to be shaped like a PLC. It's running a web server on port 80 or 443 right out of the box. That's not bare-metal firmware territory anymore. You need a real operating system to manage all those concurrent tasks without blowing your cycle time guarantees.
"execution guaranteed" is still the north star, but the path to getting there now involves a scheduler juggling multiple things.
And Nucleus is designed for exactly that. It's what's called a hard real-time operating system. The scheduler guarantees that your highest-priority task runs within a bounded amount of time, every single time. It's preemptive, it's deterministic, and it's been used in everything from medical devices to satellite systems. Siemens didn't pick it because they wanted bloat. They picked it because the old monolithic firmware couldn't scale to what customers were demanding.
That's Siemens. But you said "both" — what's the other side of this?
The other side is the broader PLC landscape. Because Siemens might be the biggest player, but they're not the only one, and different manufacturers made different bets. Rockwell Automation, which is the other giant — their ControlLogix and CompactLogix controllers run on VxWorks. That's Wind River's RTOS, and it's probably the most famous real-time operating system in the world. It's flown on Mars rovers. It's in the Boeing 787. It's everywhere. And Rockwell's been using it for decades.
If Siemens is the in-house-and-then-bought-Nucleus story, Rockwell is the off-the-shelf-and-proud-of-it story.
And then you've got companies like Beckhoff, which took an even more radical approach. Beckhoff's TwinCAT system doesn't run on a traditional PLC architecture at all. It runs on top of Windows. You take a standard Windows PC, you install TwinCAT, and it adds a real-time kernel that runs alongside the Windows kernel. The PLC logic executes in the real-time context, completely isolated from Windows, with deterministic cycle times down to fifty microseconds. Meanwhile Windows handles the HMI, the database logging, the web interface. It's a dual-kernel architecture that basically says: why build dedicated PLC hardware when you can just carve out a real-time partition on commodity hardware?
That's wild. So you've got Windows running Outlook and Excel on the same box that's controlling a factory line.
That's exactly the point Beckhoff makes. They call it PC-based control. It's been their whole philosophy since the company was founded in the 1980s by Hans Beckhoff. The industrial PC is the controller. And it works — TwinCAT is deployed in some of the largest manufacturing facilities in the world. But it also introduces a threat surface that a traditional PLC doesn't have. If someone compromises the Windows side, they might not be able to touch the real-time kernel directly, but they can certainly mess with the engineering workstation that's programming it.
Right, because the programming environment is sitting in Windows land. So even if the runtime is isolated, the development toolchain isn't.
That's been the source of a lot of security discussions over the past few years. But getting back to the operating system question — you also have manufacturers using QNX. That's the BlackBerry-owned RTOS, and it's used in some specialized controllers, particularly in the process industries. It's also the basis for a lot of safety-certified systems because QNX has a long history of certifications for things like IEC 61508, which is the functional safety standard for industrial systems.
We've got proprietary Siemens firmware, Nucleus, VxWorks, Windows-plus-real-time-kernel, QNX. That's already more variety than I think most people expect when they hear "PLC.
We haven't even gotten to the open-source side yet. That's where things get really interesting.
Linux is showing up in PLCs now?
It's been showing up for a while, but cautiously. The main challenge with Linux is that the stock kernel isn't hard real-time. You can add the PREEMPT_RT patch, which brings the kernel much closer to real-time performance, and that patch has been gradually mainlined over the years — as of kernel version 6.12, which came out in late 2024, most of the PREEMPT_RT code is finally in the mainline kernel. But it's still not the same as a purpose-built RTOS with formal guarantees. For a lot of industrial applications, "close to real-time" isn't good enough.
Because "close" means you missed a cycle, and missing a cycle means your bottle-filling machine just overfilled three hundred bottles.
Or worse — your safety system didn't respond within the required safety interval. So Linux tends to show up in the places where the real-time requirements are softer. Edge gateways, data aggregators, protocol converters. Things that sit next to the PLC and handle the IT-to-OT bridge. Companies like Advantech and Moxa build industrial Linux devices that talk to PLCs over PROFINET or EtherNet/IP and then push data up to cloud platforms. That's where Linux is dominant. But at the actual control level? The PLC itself? It's still overwhelmingly RTOS territory.
There's an interesting exception though — Codesys. That's not an operating system, but it's a runtime that sits on top of various operating systems, right?
Codesys is a development environment and a runtime engine, and it's massively important but often overlooked. It originated from a German company called 3S-Smart Software Solutions, now part of the Codesys Group. The idea is that you write your PLC program once in the Codesys IDE using IEC 61131-3 languages — ladder logic, structured text, function block diagram — and then you can deploy that same program to hundreds of different hardware platforms from different manufacturers. Underneath, the Codesys runtime is running on whatever OS the hardware uses. So you might have Codesys on top of Linux, on top of VxWorks, on top of Windows, on bare metal. It's an abstraction layer that makes the underlying OS somewhat invisible to the application developer.
Which is great for portability and absolutely terrifying from a supply-chain perspective. If there's a vulnerability in the Codesys runtime, it doesn't matter what OS you're running underneath.
We saw exactly that scenario. In 2022 there was a series of critical vulnerabilities disclosed in the Codesys runtime — CVE-2022-31800 through 31806, I believe. Remote code execution, denial of service, the full buffet. And because Codesys is used by something like a thousand different device manufacturers, the blast radius was enormous. That's the tradeoff of abstraction layers. They make development faster and cheaper, but they also create monoculture risk.
A thousand manufacturers running the same runtime. That's the industrial equivalent of every website running the same JavaScript library.
It's exactly that. And it's a dynamic that the industrial world is still grappling with. In IT, we've had decades of learning to manage software supply chains. In OT, a lot of these devices were designed in an era when nobody imagined they'd be connected to anything except maybe a proprietary fieldbus. The idea that someone in a different country could reach out and touch a PLC over TCP/IP just wasn't part of the threat model.
Let me pull us back to the core of the question. The ESP32 comparison. Is that fair?
For some PLCs, it's surprisingly close. An ESP32 runs FreeRTOS or sometimes bare-metal code in the Arduino environment. You write your logic, it compiles down to machine code, and it runs directly on the processor with nothing between your code and the hardware except maybe a thin task scheduler. That's essentially what the older S7-300 and S7-400 firmware is doing. It's a monolithic binary that handles everything — the scan cycle, the I/O update, the communication tasks — all in a single executable image running directly on the processor. No process isolation, no memory protection between tasks, no user space versus kernel space. Everything runs in privileged mode.
Which is great for performance and determinism, and really bad for security. If any part of that firmware has a bug, you've got full system compromise.
That's exactly why the industry has been moving toward systems like Nucleus and VxWorks that provide memory protection and process isolation. The S7-1500 with Nucleus, for example — the real-time control logic runs in one context, the web server runs in another, the PROFINET stack runs in a third. If someone compromises the web server, they don't automatically own the control logic. That's a meaningful security boundary that simply didn't exist in the older architecture.
The trajectory is toward more layers, not fewer. More complexity under the hood, in service of both more features and more security isolation.
That's the tension. Every layer you add is a potential source of bugs and vulnerabilities. But the alternative — a monolithic firmware blob where everything runs in the same address space — is arguably worse in a connected world. At least with proper isolation, you can contain the damage. It's the same argument we've been having in general-purpose computing for decades, just arriving late to the industrial world.
There's another dimension to this that Daniel's question hints at but doesn't explicitly ask. What about the development workflow? When you're programming one of these things, are you aware of the operating system at all?
And that's by design. The whole philosophy of PLC programming, going back to the original Modicon 084 in 1969, is that the control engineer should not need to know anything about the underlying computer. You program in ladder logic, which looks like electrical schematics, because the target user was an electrician who understood relay circuits, not a software developer who understood C. That philosophy has persisted. The Siemens TIA Portal, the Rockwell Studio 5000, the Codesys IDE — they all present a world where you're programming a "controller," not a computer running an operating system.
It's the ultimate abstraction. The OS is someone else's problem.
Until it isn't. Until you need to do something the abstraction doesn't cover. Until there's a vulnerability in the runtime and you need to understand what's actually happening. Until you're trying to integrate a PLC with a modern DevOps pipeline and suddenly you're staring at firmware versions and kernel configurations. The abstraction leaks.
That's the moment when an industrial controls engineer discovers they've been a systems programmer all along and nobody told them.
It's happening more and more. The convergence of IT and OT means that the traditional walls are crumbling. You've got PLCs with embedded web servers, with OPC UA endpoints, with MQTT clients, with REST APIs. These are not relay replacements anymore. They're network-connected computing devices that happen to have screw terminals on the front. And the people managing them increasingly need to understand both worlds.
Let's talk about the real-time guarantee for a second, because that's the thing that separates all of these from a Raspberry Pi running Python. What does "hard real-time" actually mean in practice for a PLC?
It means the system can guarantee that a specific task will complete within a specific time window, every single time, no exceptions. A typical PLC scan cycle works like this: read all the inputs, execute the control program, write all the outputs, handle communication, repeat. That cycle has a deadline. For a motion control application, that deadline might be one millisecond or even less. If you miss the deadline, the physical process goes wrong — the motor overshoots, the valve doesn't close in time, the robot arm drifts out of position.
A general-purpose OS like Windows or standard Linux can't make that guarantee because the scheduler might decide to run a disk defragmentation or a virus scan at exactly the wrong moment.
The technical term is "unbounded latency." In a general-purpose OS, the time between when an interrupt fires and when your handler runs is not predictable. It depends on what else is happening in the system. In a hard real-time OS, that latency is bounded and documented. VxWorks, for example, guarantees interrupt latency under a microsecond on most supported hardware. Nucleus is in the same range. The Siemens proprietary firmware is probably even tighter because it's so stripped down.
When Daniel compares it to an ESP32, he's not wrong in spirit. The ESP32 running FreeRTOS is also making real-time guarantees, just at a much smaller scale.
The ESP32 is a microcontroller. A PLC like the S7-1500 has a proper applications processor — often an ARM Cortex-A series or something comparable — with a memory management unit, cache, multiple cores. It's a much more capable piece of silicon. But the software architecture shares a lot of DNA. The RTOS on the PLC is doing what FreeRTOS does on the ESP32, just with more features and more formal verification.
I want to circle back to something you mentioned earlier about Siemens acquiring Mentor Graphics. That was 2017. That means Siemens has owned the company that makes the OS for their flagship PLCs for almost a decade now. Has that changed anything visible?
It's hard to see from the outside, but almost certainly yes. When you own the OS vendor, you can drive the roadmap. You can say, "we need these specific features for our next-generation controller," and they become priorities. You also get deeper integration. The S7-1500's firmware and the Nucleus kernel are probably co-developed to a degree that wouldn't be possible if Mentor were an independent company. And from a security perspective, owning the full stack means you're not waiting on a third party to patch vulnerabilities.
Though it also means if there's a systemic issue, it's entirely your problem.
No one else to blame. But Siemens seems comfortable with that. They've been vertically integrating for years — they bought UGS for product lifecycle management software, they bought Mentor for electronic design automation and the RTOS, they've built out their own chip design capabilities. The vision is clearly to own the entire industrial automation stack from silicon to cloud.
Which is a very different philosophy from the Beckhoff approach of "just use Windows and commodity hardware.
It's the classic vertical integration versus horizontal platform play. Siemens wants to be Apple. Beckhoff wants to be more like Android — or at least like the PC ecosystem. Both approaches have proven successful, and they coexist because different customers have different priorities. A pharmaceutical plant with regulatory validation requirements might prefer the fully integrated Siemens stack where everything is certified together. A flexible manufacturing line that needs to integrate with all sorts of IT systems might prefer the Beckhoff approach.
What about safety? You mentioned IEC 61508 earlier. How does the operating system choice affect safety certification?
Safety certification is one of the biggest drivers of OS choice in industrial systems. If you're building a safety instrumented system — something that shuts down a reactor or stops a press before it crushes someone's hand — you need to prove to a certification body that your software won't fail in dangerous ways. That means you need an OS that has either been pre-certified or that you can certify yourself. VxWorks has a long history of safety certifications, including DO-178C for avionics and IEC 61508 for industrial. QNX has the same. Nucleus has been certified for medical devices and industrial safety. Siemens' proprietary firmware is certified as part of the overall S7 system.
Linux is a nightmare for safety certification. The kernel is millions of lines of code that change constantly. The development process is not documented to the level that certification bodies require. There have been efforts — the ELISA project, the Linux Foundation's Enabling Linux in Safety Applications initiative — but it's slow going. If you need SIL 3 or SIL 4 certification, you're almost certainly not running Linux directly. You might run a tiny certified RTOS alongside Linux, with the safety functions on the RTOS and everything else on Linux.
The safety-critical stuff stays on the tiny, verified kernel, and the fancy web dashboards and cloud connectors live on the big, complex OS.
That's the pattern, and I think we'll see more of it. Heterogeneous systems where a single piece of hardware runs multiple operating systems side by side, with hardware-enforced isolation between them. The PLC becomes a system-on-chip with an RTOS for control, Linux for connectivity, and maybe a separate security processor handling authentication and encryption.
That sounds expensive.
It is, but it's getting cheaper. The silicon to do that kind of virtualization used to require expensive FPGAs or dedicated multi-chip solutions. Now you can get ARM processors with TrustZone and hardware virtualization support for a few dollars. The economics are shifting.
Let's step back to something more concrete. If someone is looking at a PLC in a factory today — say a Siemens S7-1500 running a production line — and they want to know what operating system is inside, how would they find out? Is it documented anywhere?
It's not advertised on the spec sheet, which is part of why Daniel's question is so good. Siemens doesn't say "powered by Nucleus" in their marketing materials. The documentation calls it the "S7 firmware" or the "controller operating system." You have to dig into technical manuals, security advisories, or firmware analysis to figure out what's actually running. The industrial automation industry has historically treated the OS as an implementation detail, not a selling point.
Which is wild when you think about it. In every other domain of computing, the operating system is a major part of the product identity. Nobody buys a phone without knowing whether it runs iOS or Android. But in industrial automation, you can spend a hundred thousand dollars on controllers and never be told what kernel they boot.
That's starting to change, partly because of security. When the ICS-CERT advisory comes out saying "this version of VxWorks has a critical vulnerability," asset owners suddenly need to know if any of their devices are running VxWorks. The old attitude of "it doesn't matter, it's just a PLC" becomes untenable when you're trying to do vulnerability management across a fleet of thousands of devices.
The abstraction is being forcibly peeled back by the security requirements of the connected world.
And it's uncomfortable for everyone. The vendors don't want to expose their internals. The users don't necessarily want the complexity. But the alternative is running devices with known vulnerabilities because you can't figure out what's inside them.
We've been talking mostly about the big players. What about the smaller or more specialized PLCs? Are there interesting outliers in the OS landscape?
A few worth mentioning. There's a whole category of soft PLCs — software-only controllers that run on standard industrial PCs. We mentioned Beckhoff with TwinCAT, but there's also Bosch Rexroth with their ctrlX CORE, which is built on top of Linux with a real-time kernel and uses an app-based architecture. They're essentially saying the PLC is an app platform, and you can download control functions from an app store. It's a radical rethinking of what a controller is.
An app store for factory control. That's either brilliant or terrifying.
Bosch Rexroth launched ctrlX World in 2020 and it's been gaining traction, particularly in Europe. The idea is that you have a base Linux system with real-time extensions, and then you add control functions as containerized apps. Want PLC functionality? Download the PLC app. Want motion control? Download the motion app. Want an OPC UA server? There's an app for that. It's the smartphone model applied to industrial automation.
Each app is a container, so there's isolation between them?
Yes, they use containerization — Docker-style containers or something similar — to isolate the apps. It's a very modern software architecture applied to a domain that's been running the same basic model for fifty years.
If the Siemens approach is vertical integration and the Beckhoff approach is dual-kernel on Windows, the Bosch Rexroth approach is Linux plus containers plus app store. That's three fundamentally different philosophies, all coexisting in the same market.
They're all successful in their niches. That's what makes this space so interesting. It's not a monoculture. There's genuine architectural diversity, driven by different assumptions about what a controller should be and who should program it.
You mentioned containerization. Are we going to see Kubernetes on the factory floor?
People are trying. There's a whole edge computing movement that wants to bring cloud-native patterns to industrial environments. The challenge is that Kubernetes wasn't designed for hard real-time. The control plane itself introduces latency and unpredictability. But for the non-real-time parts — the data processing, the analytics, the machine learning inference — it makes a lot of sense. I've seen architectures where the real-time control runs on a traditional PLC or RTOS, and then a separate edge node running Kubernetes handles everything else, with a deterministic link between them.
The factory becomes a distributed system with different nodes optimized for different workloads.
That's already happening. The term people use is "converged IT-OT architecture." It's messy, it's complicated, and it's where the industry is headed whether anyone likes it or not.
Let me ask you a question that's been in the back of my mind. All these operating systems you've described — VxWorks, Nucleus, QNX, the Siemens proprietary firmware — they're all closed-source, or at least source-available only under strict licensing. Does that matter? Is there an argument for open-source RTOS in industrial control?
There's an argument, and there are a few open-source RTOS options out there. FreeRTOS is the most famous — it's now owned by Amazon through their acquisition of FreeRTOS.org, and it's used in millions of microcontrollers. But FreeRTOS is really designed for the microcontroller class, not the applications-processor class that a high-end PLC uses. There's also Zephyr, which is a Linux Foundation project that's more capable and is gaining adoption in industrial IoT devices. And then there's seL4, which is a formally verified microkernel developed by NICTA in Australia and now maintained by the seL4 Foundation.
Formally verified — meaning they've mathematically proven properties about it?
seL4 is the only general-purpose operating system kernel that has been formally verified for functional correctness. They've proven, using machine-checked mathematical proofs, that the C implementation correctly implements its specification. That's an extraordinary achievement. The proofs cover things like memory safety, absence of buffer overflows, absence of null pointer dereferences. For a safety-critical industrial controller, that's incredibly valuable.
Why isn't everyone using seL4?
Because formal verification is hard and the ecosystem is small. The kernel itself is verified, but the drivers, the network stack, the application frameworks — those aren't. And the performance characteristics, while good, haven't been optimized for industrial control the way VxWorks or Nucleus have over decades. Plus, the industrial world is conservative. "Nobody got fired for buying Siemens" is a real thing. The switching costs are enormous. If you've got a factory running on Siemens controllers with twenty years of accumulated ladder logic, you're not going to rip it all out because someone proved a theorem about a different kernel.
The installed base is the ultimate moat.
It's an incredibly deep moat. And it's not just the hardware and software — it's the training, the tooling, the spare parts inventory, the service contracts, the regulatory certifications. All of that is tied to a specific vendor's ecosystem. Changing operating systems means changing all of that.
What you're saying is, the answer to "what OS does a PLC run" is partly technical and partly a story about industrial economics and path dependency.
The technical answer is: it depends on the manufacturer and the model year, but you'll find proprietary RTOS, VxWorks, Nucleus, QNX, Windows with real-time extensions, and increasingly Linux in non-critical roles. The deeper answer is that the OS choice is embedded in a web of business decisions, certification requirements, and legacy compatibility that makes it very sticky.
If you're an attacker looking at this landscape, the diversity is both a challenge and an opportunity. A challenge because you can't write one exploit that works everywhere. An opportunity because each of these platforms has its own vulnerabilities, and the defenders are often struggling just to know what they're running.
That's the security paradox of industrial control systems in a nutshell. The diversity provides some natural resilience against mass exploitation, but the opacity makes it very hard to defend systematically. You can't patch what you can't inventory.
Let me ask one more question before we wrap. If Daniel — or anyone — wanted to actually run one of these RTOSes and experiment with it, is that possible? Can you just download VxWorks and play around?
VxWorks is commercial. Wind River offers evaluation licenses, but it's not open source and it's not free. Nucleus is the same — you can get an evaluation kit from Siemens, but it's a commercial product. QNX offers free non-commercial licenses for experimentation, which is actually quite generous. FreeRTOS is fully open source and free to use, even commercially, under the MIT license. Zephyr is Apache 2.0 licensed and completely open. seL4 is open source under GPLv2. So there are options if you want to get your hands dirty.
None of them will give you the exact experience of programming a Siemens PLC, because the RTOS is hidden behind the engineering tool.
The PLC experience is the IDE — TIA Portal, Studio 5000, Codesys. The operating system underneath is deliberately invisible. If you want to understand what's actually happening, you almost have to approach it from the security research angle. Look at the firmware, analyze the binaries, figure out what's running. It's a different kind of exploration.
That feels like a good place to leave it. The PLC operating system landscape is more diverse and more layered than it appears from the outside, and the trend is toward more complexity, not less — but that complexity is in service of features, security isolation, and connectivity that the old monolithic firmware could never support. The ESP32 comparison isn't wrong, it's just at one end of a spectrum that now stretches all the way to containerized app platforms.
The thing I'd want people to take away is that the invisibility of the OS is a deliberate design choice that made sense in 1970 and is becoming a liability in a world where everything is connected. The abstraction is leaking, and understanding what's underneath matters more than it used to.
Now: Hilbert's daily fun fact.
Hilbert: The name "Sakhalin" comes from a misrendering of the Manchu phrase "sahaliyan ula angga hada," meaning "cliffs at the mouth of the black river." When Russian explorers first mapped the island in the early nineteen hundreds, they truncated the phrase to just the first word, misunderstood it as a proper name, and the error has been baked into every map since.
Truncation errors with geopolitical consequences. Sounds about right.
That's one for the next trivia night.
Something to chew on: if the trend continues, the PLC of 2035 might not look like a PLC at all. It might be a software workload running on a general-purpose edge server, containerized and orchestrated, with the real-time guarantees handled by a hypervisor we haven't heard of yet. And the question of "what operating system" will be even harder to answer, because the answer might be "several, simultaneously." That's either progress or a very elaborate way to recreate the problems we already solved with dedicated hardware.
Probably both is the safest bet in this industry. Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. Find us at myweirdprompts.com or wherever you get your podcasts.
We're back next time.
