View in web for best experience
Happy August 10th, Industry 4.0!
The dog days of summer usually mean things slow down — plants run lean crews, everyone's saving PTO for Labor Day, and the loudest thing on the floor is the box fan in the break room. Not this week.
While you were checking IMTS 2026 booth assignments (it's in Chicago this September, in case that snuck up on you), Siemens quietly shipped Git branching and VS Code into its PLC and HMI engineering tools. Yes, you read that right — your automation engineers are about to have the same "merge conflict" headaches your software team has had for years.
Meanwhile, the plant floor's growing appetite for AI agents means it's now wired into the same infrastructure IT has been sweating over for a decade — which is exactly why a researcher quietly patching a widely-embedded OPC UA library, and Rockwell Automation's rough couple of weeks, both matter a lot more than they would have five years ago. And on the AI-agent side, industrial data providers are racing to make their data "speak MCP," for better or worse.
The throughline this week: the wall between "industrial engineering" and "software engineering" keeps getting thinner. That's good news for velocity and bad news for anyone who thought OT was exempt from IT's headaches.
Here's what caught our attention:
Siemens just extended its SIMATIC AX engineering platform beyond PLC programming and into visualization — bringing branching, pull requests, and YAML-based project files to a discipline that's largely still drag-and-drop.
The details:
- SIMATIC AX WinCC Unified Elements launched July 28, initially exclusive to the US market
- Built on Visual Studio Code, with native Git integration (branching, merge requests, project history) and an extension marketplace (Open VSX)
- Full project generation from YAML files — automation projects get built by combining AI-generated code, configs, scripts, and reusable library packages
- Hybrid workflows let engineers work in the drag-and-drop graphical editor and the code editor at the same time, synced in real time
- Plays nice with CI/CD pipelines from GitHub, GitLab, Azure DevOps, and Bitbucket
- For now, it only supports WinCC Unified PC Runtime — panel-based HMI runtimes aren't included yet
Why it matters for manufacturing:
Translation: your control engineers are about to inherit the same tools — and the same headaches — your software team has used for years. That's not a knock. Version control means you can finally answer "who changed this HMI screen and why" without digging through email threads. Branching means two engineers can work on the same visualization project without overwriting each other's changes. CI/CD support means "push to test, then push to production" becomes a real workflow instead of a manual file copy at 2 AM.
Real-world scenario:
Your HMI team is mid-sprint on a new dashboard for Line 3, and someone needs to hotfix a broken alarm threshold on Line 1 — today. With Git-based workflows, that's a quick branch, a fix, a merge request, and a deploy, without touching the in-progress dashboard work. Try doing that cleanly in a single shared project file today.
The catch: this is US-only for now, and it only talks to WinCC Unified PC Runtime, so if you're running panel-based HMIs or you're outside the US, you're watching from the sidelines. Siemens is calling this a "market validation phase" — corporate-speak for "we're seeing if this sticks before we commit further."
The bottom line:
Siemens isn't just automating your production line anymore — it's automating the automation itself. If your team already lives in Git for software work, this is the first real sign that PLC and HMI engineering are about to look a lot more like software engineering.
Read the announcement →
Read the technical deep dive →
The OPC UA Library Half Your Industrial Stack Doesn't Know It's Running Just Got Patched
An independent security researcher found two memory-corruption bugs in open62541 — one of the most widely embedded open-source implementations of OPC UA, the protocol that lets your PLCs, historians, and SCADA systems talk to each other.
The details:
- Two vulnerabilities: one lets an attacker crash a server by sending a single malformed network packet (no login required); the other is a "use-after-free" bug — a flaw where the software tries to use a chunk of memory it already freed, which can crash a service or, in the wrong hands, be leveraged for worse
- Both affect open62541 versions 1.3.0 through 1.5.5 — a huge range, spanning years of releases
- CISA published the official advisory (ICSA-26-211-08) on July 30; fixed versions (1.3.19, 1.4.18, 1.5.6) shipped July 27
- The researcher followed textbook responsible disclosure: reported it in May, worked privately with the maintainers, and only went public once patches existed
- Here's the catch: open62541 isn't something you "install and patch" — it gets compiled directly into other products. It's inside Qt's OPC UA plugin, Intel's industrial edge software, and even Arduino's official OPC UA library for its Opta controllers
Why it matters for manufacturing:
This is the quiet, unglamorous risk that doesn't make headlines the way ransomware does: a library baked into dozens of products you may not even know you're running. Your OPC UA server might not be "open62541" branded anywhere — it's just quietly doing the talking underneath a vendor's HMI software, an edge gateway, or a cheap PLC add-on board. When the upstream library gets patched, that fix doesn't magically reach you. Someone downstream — the vendor — has to notice, rebuild, and ship an update. That gap is where the real exposure lives.
Real-world scenario:
Say your plant runs an edge gateway that quietly bridges PLC data to your historian over OPC UA. If that gateway's vendor built it on an old open62541 release and hasn't pushed an update since, you're carrying this risk without any obvious symptom — until someone on your network (intentionally or not) sends the wrong packet and that gateway drops offline mid-shift.
The bottom line:
Ask your OPC UA vendors — gateways, historians, edge devices, even that Arduino-based sensor project — what version of open62541 they're built on, and whether they've shipped a fix. If they don't know, that's your answer.
Read the full technical writeup →
Rockwell's Rough Two Weeks: An Authentication Bypass and 4,400 Exposed PLCs in Active Attacks
If you run Rockwell Automation gear, the last two weeks gave you two separate reasons to check your network — one's a bug you need to patch, the other is a wake-up call about what's already sitting exposed on the internet.
The details:
- Issue 1 — FactoryTalk auth bypass (ICSA-26-202-07): CISA disclosed a JWT "algorithm confusion" bug in FactoryTalk Services Platform 6.60's Okta Web Authentication. An attacker can submit a token with no valid signature and the system accepts it anyway, letting them impersonate any authorized user. FTSP is the identity backbone for FactoryTalk View, Historian, and AssetCentre — one forged token can potentially reach all of them. Rockwell rates it high severity; the fix is patch RAID 1158263 or the February 2026 Patch Roll-up.
- Issue 2 — Real attacks on exposed PLCs: Separately, Forescout found 4,400+ internet-facing Rockwell PLCs worldwide (65% in the US), reachable through a single open port (44818) with no exploit required. The FBI confirmed attackers used exactly that access to hit water utilities in 12+ states in late July — changing passwords and reconfiguring MicroLogix controllers in Minnesota, Michigan, South Dakota, and Georgia. New York responded with $9M in emergency grants for 153 water systems.
Why it matters for manufacturing:
These are two different failure modes worth understanding separately. The FactoryTalk bug is a software flaw — you patch it and move on. The PLC exposure is a configuration and network-design problem — someone, at some point, put a controller on a network path that reaches the public internet, often through a cellular router nobody's watching closely. Water utilities got hit first because a lot of them run lean IT/OT teams. Manufacturing plants running the same exposed device classes aren't a different risk category — they're just further down the target list.
Real-world scenario:
Your remote site has a MicroLogix controller talking back to HQ over a cellular gateway installed years ago by an integrator who's long gone. Nobody's audited that connection since. That's precisely the setup Forescout flagged — and precisely how 22 of those water utility PLCs got found and hit.
The bottom line:
Patch FactoryTalk if you're on 6.60. Then go find out whether any of your PLCs — especially ones on cellular or VPN gateways — are reachable from the open internet on port 44818. If you don't know the answer, that's this week's action item.
FactoryTalk advisory →
Water utility attacks →
Your Industrial Data Provider Just Learned to Speak Claude and ChatGPT's Language
Industrial Info Resources — the outfit that's been tracking capital projects, plant equipment, and outages since before "digital transformation" was a phrase — just launched an MCP server, meaning its 40 years of human-verified industrial data can now be queried directly from an AI assistant conversation.
The details:
- IIR Envoy™ MCP launched August 6, connecting Industrial Info's Global Market Intelligence platform and IIR Energy services to AI assistants like Claude and ChatGPT via the Model Context Protocol
- Covers capital projects and spending, plants and industrial equipment, planned and unplanned outages, company ownership records, and industrial activity across global markets
- It's not a public firehose — IIR Envoy is only available to existing Industrial Info and IIR Energy subscribers, so the underlying data stays behind the same commercial access layer it's always had
- MCP itself, explained plainly: it's a standard way for an AI assistant to reach out to an external data source mid-conversation, pull structured information, and use it to answer your question — instead of you tabbing over to a separate tool, searching, and copy-pasting the answer back
Why it matters for manufacturing:
If you've been reading this newsletter, you've seen MCP mentioned more than once this year — it's quietly becoming the plumbing that connects AI assistants to the tools and data you already pay for. IIR putting its research behind an MCP server is a signal that "make our data AI-queryable" is moving from novelty to expected feature for industrial data and market intelligence vendors. Expect your other vendors — ERP, MES, historian, market research — to follow.
Real-world scenario:
Picture your plant engineering team evaluating a new supplier or scoping a capital project. Instead of logging into IIR's portal, running a search, exporting a report, and pasting the numbers into a summary for leadership, someone just asks their AI assistant directly: "What capital projects has [competitor] announced in the Gulf Coast in the last six months?" — and gets a sourced answer pulled from IIR's actual research, in the same conversation where they're already working.
The bottom line:
This isn't a tool you can use for free, and it won't replace your analysts. But it's a preview of where industrial data access is headed: less "log into another portal," more "just ask." If you're already an IIR or IIR Energy subscriber, this is worth a look. If you're not, it's a reason to start asking your other data vendors when their MCP server is coming.
From the Floor: This Week in the Community
Discord was busy this week, and not in the "someone posted a meme" way—in the "people are actually wrestling with hard problems" way. Here's what stood out from August 3rd through the 9th.
The downtime debate that won't die: Over in #mes and #digital-transformation, a genuinely useful argument broke out about how to log downtime correctly. The sticking point: trigger vs. root cause. A PLC throws a first-out fault—that's the trigger. But the actual reason the line stopped might be a material shortage three steps upstream. Sound familiar? If your OEE numbers look clean but your maintenance team keeps shrugging at them, this is probably why. The thread didn't land on a single answer (nobody ever does), but it's worth a look if you're building out downtime codes.
AI agents are changing how people work—for better and worse: The most active conversation of the week happened in #ai-and-ml and #digital-transformation, and it got refreshingly honest. Members are using AI agents to write code and build tools faster than ever—one person described it as a "software renaissance." But the flip side came up just as often: heavier workloads, disrupted sleep from late-night ideation sessions, and the low-grade anxiety of trying to keep pace with what big tech ships every week. Translation: the productivity gains are real, but so is the burnout risk if you don't set boundaries.
New faces worth knowing:
- Matt (the_kennyb) — a controls engineer building a modular MES and digging into Unified Namespace
- sans — got into Industry 4.0 through, of all things, a Roblox game (proof the pipeline into this industry is getting weirder and wider)
- jjohnston_capsher_37360 — a software engineer focused on IoT and system integration
Friday Wins keeps delivering: Joshua Stover's Friday Wins thread in #general is turning into a real community anchor. This week's haul ranged from "I built a barn" to "I got sign-off on a major UNS proposal"—which is a pretty good summary of what this community is: people building things, literal and digital, and cheering each other on for both.
Worth checking out:
- An upcoming HighByte event on industrial data strategy—bright_hummingbird_31342 has passes available if you're interested
- The ProveIt! Conference sessions are now on YouTube
- Ultrashock teased plans to open-source parts of their Phaseshift industrial AI platform—one to watch
Still open: If you've got a solid answer for monitoring apps across edge and cloud (specifically MQTT broker availability alerts) beyond NetData, drop it in #product-recommendations—that thread's still looking for enterprise-grade options.
Not in the room yet? Come hang out in the Discord → — that's where the real work gets argued out.
Byte-Sized Brilliance
Here's a number worth knowing: South Korea now has 1,220 industrial robots for every 10,000 manufacturing employees—the highest robot density on the planet, according to the International Federation of Robotics' newly released World Robotics 2025 report.
Do the math and that works out to roughly one robot for every eight human workers on a South Korean factory floor. The global average? A comparatively quiet 132 robots per 10,000 workers—meaning Korea isn't just in first place, it's lapping the field almost 10 times over.
Picture a mid-sized plant with 800 employees. Statistically, about 100 of the "workers" on that floor aren't clocking in for a paycheck—they're welding, painting, and moving parts around the clock, no coffee breaks required.
Which raises the real question: is your plant's robot count keeping pace, or still stuck in the single digits?
Let us know how we're doing! https://forms.gle/zSXrKTK9BNZ3BrpXA
Responses