4 Things Industry 4.0 08/17/2026

View in web for best experience
Happy August 17th, Industry 4.0!
IMTS opens in Chicago in less than three weeks, and if the pre-show press releases are any indication, this year's theme is "buy more robots and put AI in all of it." Fair enough — it's the new shiny thing.
But while manufacturing keeps writing checks for automation, digital twins, and imaging systems, this week was a reminder that connectivity is a two-way street. A critical VMware vCenter flaw went from patch to active exploitation in under five days, and it's spreading through the same virtualized infrastructure a lot of plants now lean on for historians and OT systems management.
So this issue is a bit of a split personality: half growth story, half gut check. Robot orders are up. Semiconductor makers are extending digital twins from the design bench onto the fab floor. Teledyne just wrote a nine-figure check for an imaging company. And then there's the small matter of attackers getting into vCenter servers faster than most IT teams can patch them.
We're also taking a hard look at the Purdue Model this week — the reference architecture half the industry treats as gospel for OT security. Spoiler: "security-first" might be doing some heavy lifting in that reputation.
Here's what caught our attention:

If your plant runs virtualized servers on VMware, this is the kind of story that should interrupt your coffee break.
The details:
- On July 29, 2026, Broadcom (which owns VMware) disclosed a critical vulnerability in vCenter Server — the management console that lets IT teams control virtual machines (VMs) across a network from one dashboard. Think of vCenter as the control tower for every virtual server you're running, including ones tied to historians, OT data collection, or plant IT infrastructure.
- The flaw, tracked as CVE-2026-59310, scored a 9.8 out of 10 on the severity scale (CVSS). It's a "directory traversal" bug, which is a fancy way of saying an attacker can trick the system into running code it was never supposed to touch — no username or password required.
- Attackers started exploiting it just five days after the patch came out. By August 7, security researchers had confirmed 361 compromised servers across 47 countries, with more than half concentrated in Germany, the U.S., Turkey, Iran, and France.
- Once inside, attackers are installing a tool called reverse_ssh — it opens a hidden, outbound connection back to them, which slides right past most firewalls since it looks like normal outgoing traffic.
Why it matters for manufacturing:
A lot of plants don't think of vCenter as "their" system — it's IT's problem, right? Except vCenter increasingly sits underneath things the plant floor absolutely depends on: virtualized historians, SCADA servers, MES instances, engineering workstations. If vCenter gets popped, an attacker doesn't just get IT's file shares. They potentially get a foothold one hop away from production systems.
Real-world scenario: Your plant's historian runs as a VM under vCenter, managed by a shared IT/OT team. Nobody's patched vCenter yet because "we'll get to it next maintenance window." An attacker doesn't need your HMI credentials — they walk in through vCenter, land on the same virtual infrastructure your historian lives on, and now they're one lateral move from your production network. This is exactly the kind of blended IT/OT risk that a "patch it eventually" mentality can't survive anymore.
The bottom line: If you have any virtualized infrastructure — even infrastructure you think of as "IT's" — check whether it's touching vCenter, and check whether it's patched. Five days between disclosure and active exploitation doesn't leave room for a leisurely maintenance schedule.
North American Robot Orders Are Climbing — Just Not Where You'd Expect
The robots are still coming. They're just coming from different industries than they used to.
The details:
- The Association for Advancing Automation (A3) reported that North American companies ordered 8,940 robots worth $622 million in Q2 2026 — a 4.3% increase in units and a 21.3% jump in order value compared to Q2 2025.
- First-half 2026 totals now sit at 17,995 units valued at $1.166 billion, up 2.0% in units and 6.6% in value over the first half of 2025.
- Here's the twist: automotive — historically the biggest buyer of industrial robots — stayed soft. The growth came from food, electronics, and healthcare manufacturers picking up the slack.
- Order value growing faster than order volume (21.3% vs. 4.3%) tells its own story: buyers aren't just ordering more robots, they're ordering pricier, more capable ones — think higher payloads, vision systems, AI-assisted motion planning.
Why it matters for manufacturing:
For years, "robot orders" basically meant "automotive orders." That's no longer true, and it's worth paying attention to who's actually buying. If you're a food & beverage or electronics manufacturer sizing up automation, you're not an outlier chasing a trend anymore — you're now part of the group actually driving the growth numbers. That changes what kind of case studies, integrators, and support are going to be available to you going forward, since vendors follow the money.
Real-world scenario: You run a mid-sized food processing plant and you've been eyeing a palletizing robot for two years but kept getting told "that's really an automotive thing." Except automotive demand has cooled while food, electronics, and healthcare buyers have become the actual growth engine A3 is reporting on. Translation: you're not early to this anymore, and neither is your integrator's next candid conversation about lead times.
Action items:
- If your industry falls into food, electronics, or healthcare, expect more vendor attention (and possibly better lead times/pricing) as suppliers chase where the growth actually is.
- Look at the order-value trend, not just unit counts — the market is buying more capable systems, not just more of the same.
- If automotive is your bread and butter, don't assume automation demand overall is soft — it's shifting, not shrinking.
The bottom line: The center of gravity in industrial robotics has quietly shifted away from automotive. If your plant isn't a car factory, this might be the best window you've had in years to get vendor attention.
Semiconductor Manufacturers Are Extending Digital Twins Off the Design Bench and Onto the Fab Floor

For decades, chip designers have used digital twins to simulate silicon before it's ever manufactured. Now that same concept is spreading into how the chips actually get made.
The details:
- A digital twin is a virtual model that mirrors a real, physical thing closely enough that you can test changes on the model instead of the actual equipment. Semiconductor companies have used them for chip-level design for decades — simulating how a circuit will behave before committing to expensive, complex fabrication.
- What's new: manufacturers are extending the digital twin concept beyond design and into fab operations — the actual factories where chips get made. That means connecting design data, equipment behavior, and production performance into one continuous digital thread instead of three disconnected systems.
- The driver is a squeeze from both directions. Chip designs keep getting more complex (smaller transistors, higher power density, tighter tolerances), which balloons the engineering effort required. At the same time, industrial AI is delivering real gains — but only where design, manufacturing, and fab operations aren't siloed off from each other.
- Success depends on three things: strong cybersecurity, clean data integration, and secure collaboration across teams that historically didn't share systems (design engineers and fab operators often work in entirely separate toolchains).
Why it matters for manufacturing:
This isn't just a semiconductor story — it's a preview. Digital twins moving from "design-only" tools into full operational twins that span the entire product lifecycle is the same pattern showing up across discrete manufacturing broadly. If you've experimented with digital twins for a single machine or line, semiconductor makers are showing what it looks like to connect that all the way from initial design through to the shop floor.
Real-world scenario: Picture a fab where a chip design change historically took weeks to validate because engineering had to physically test it on the line, hand off findings back to design, and repeat. With a connected digital twin spanning design and fab operations, that loop happens virtually first — catching problems before they ever touch expensive production equipment. The same logic applies whether you're making chips or stamping metal: the earlier you can simulate a change, the less it costs when something's wrong.
The bottom line: Digital twins are graduating from a design-phase nice-to-have into an end-to-end operational backbone. If your plant's digital twin strategy stops at the design phase, semiconductor manufacturers are showing you what the next step looks like — and why cybersecurity and data integration have to be part of that expansion from day one, not bolted on later.
Teledyne Is Paying $1.1B for an X-Ray Imaging Company — Here's Why NDT and Inspection Buyers Should Care

If your plant does non-destructive testing (NDT) or relies on X-ray inspection systems, the imaging supply chain just consolidated a little further.
The details:
- On August 10, 2026, Teledyne Technologies (NYSE: TDY) announced a definitive agreement to acquire Varex Imaging Corporation (NASDAQ: VREX) for $18.90 per share in cash — about $1.1 billion total, including equity awards and net debt.
- That's a 52.3% premium over Varex's last closing price before the deal was announced — a significant vote of confidence from Teledyne.
- Varex makes X-ray tubes, digital flat-panel detectors, and advanced photon-counting detectors used across medical diagnostics, security screening, and industrial inspection — including the kind of non-destructive testing manufacturers use to check welds, castings, and composite parts without damaging them.
- Teledyne executive chairman Robert Mehrabian was explicit about the fit: Teledyne makes X-ray detectors but doesn't cover high-radiation environments like Varex does, and Varex is the only one of the two with advanced photon-counting detector technology for healthcare and industrial inspection.
- Deal is expected to close in early 2027, pending shareholder and regulatory approval. No financing contingency — Teledyne's using its existing credit facility.
Why it matters for manufacturing:
Teledyne isn't a household name on the plant floor, but its imaging technology quietly shows up in a lot of inspection equipment used for quality control — CT scanning for castings, X-ray weld inspection, security and cargo screening systems. When two major players in this space combine largely non-overlapping product lines, it tends to mean fewer independent suppliers, deeper integrated product lines, and — eventually — pricing and support changes for OEMs who build inspection systems around Varex components.
Real-world scenario: Your plant's quality team relies on a third-party inspection system built around Varex X-ray detectors for weld and casting verification. That OEM relationship doesn't change overnight — deals like this typically take months to close and longer to actually integrate. But a year or two from now, expect your inspection equipment vendor to be selling you on "unified Teledyne-Varex" branded systems, potentially with new pricing tiers, bundled software, or a narrower service network as things consolidate.
Action items:
- If you rely on Varex-based imaging or inspection equipment, ask your OEM/integrator directly how this acquisition affects their roadmap and support commitments.
- Don't expect immediate changes — the deal isn't projected to close until early 2027, and regulatory review could shift that timeline.
- If you're shopping for new NDT or inspection equipment, factor consolidation risk into vendor selection — fewer independent component suppliers can mean less price competition down the line.
The bottom line: This is a component-supplier acquisition, not a household name changing hands — but if X-ray inspection or NDT is part of your quality process, it's worth a mental note. The independent imaging component supply chain just got a little smaller.
Learning Lens
![]()
The Purdue Model Isn't a Security Architecture — and Treating It Like One Is the Problem
Ask ten people in this industry what protects the plant floor from a cyberattack, and at least seven will say some version of "the Purdue Model." That's worth pushing back on.
What the Purdue Model actually is:
The Purdue Enterprise Reference Architecture was introduced in 1992 as a way to organize how manufacturing systems talk to each other — sensors and PLCs at the bottom, SCADA and HMIs in the middle, ERP and business systems at the top, all stacked into numbered levels. It's an org chart for data flow. Somewhere along the way, the industry started treating that org chart as if it were a security control.
Why that's a problem now:
- Purdue's implicit promise is that you can build a trusted "inside" (OT) and keep a dangerous "outside" (IT, internet) separated by hard boundaries. That assumption is already broken: roughly 75% of OT attacks now begin as IT breaches — meaning the segmentation Purdue was supposed to guarantee is failing before you even factor in anything AI-related.
- AI is making it worse, not better. Edge inference nodes sitting inside Purdue's Level 1 and 2 — the "safe," segmented zones — aren't passive anymore. They ingest sensor data, talk to cloud platforms, and in some deployments receive live model updates. That's a live, two-way trust bridge sitting inside what everyone still assumes is an isolated zone, with no guardrails specific to that new kind of traffic.
- The framework was built for a world of deterministic systems and hard boundaries. Today's plant has AI copilots talking to cloud data lakes, predictive maintenance systems pushing alerts straight to SCADA consoles, and remote vendor access punching through the "isolated" zones on a routine basis. None of that fits cleanly into a 1992 diagram.
Here's the real failure, though — and it's bigger than one outdated diagram: "security-first" thinking, Purdue Model or otherwise, quietly trades innovation for a false sense of security. When security architecture becomes the starting point instead of a constraint you design around, you end up with plants that bolt new capability onto old assumptions instead of building the infrastructure they actually need. The Purdue Model didn't fail because it's old. It failed because manufacturers kept treating a 30-year-old data-flow diagram as a permission structure — "can we do this without breaking the levels?" — instead of asking what infrastructure would actually make them competitive, then figuring out how to secure that.
That's backwards. The plants winning right now are building scalable infrastructure with best-in-class tools first — unified namespaces, edge AI, cloud-connected historians, whatever the operation actually needs — and treating security as the engineering problem you solve second, not the gate you ask permission from first. A security-first mentality optimizes for a diagram that looks defensible in an audit. A build-first, secure-second mentality optimizes for a plant that's actually harder to attack, because it was designed around how data really moves instead of how a 1992 reference architecture assumed it would.
Where Purdue still earns its keep: as a shared vocabulary. It gives engineers, IT, and leadership a common way to talk about where something lives in the architecture. That's genuinely useful. The mistake is stopping there — using the diagram as your security posture instead of your starting map.
What this looks like in practice:
- Build the infrastructure your operation actually needs first — don't let a legacy segmentation diagram veto a UNS rollout, an edge AI deployment, or a cloud-connected historian before you've even scoped it.
- Secure what you built, not what the diagram says you're allowed to build. Pair Purdue's levels with IEC 62443's zones and conduits to define where enforcement actually needs to happen around your real architecture.
- Layer Zero Trust principles on top: verify every connection based on identity and behavior, not on which "level" a device supposedly lives in.
- Specifically account for AI/edge traffic. If a device is receiving model updates or pushing inference results upstream, it needs its own access controls — don't assume it inherits security just because it's drawn inside a "safe" zone on the org chart.
The bottom line: The Purdue Model is a decent map. It was never a lock, and it was never supposed to be the thing you build around. Manufacturers who let it — or any security-first mentality — gate their infrastructure decisions aren't protecting their plant. They're protecting a diagram, and calling it caution.
Read more → | And →
From the Floor: This Week in the Community
Discord had one of those weeks where the mid-week stretch did all the heavy lifting — a real technical argument, some genuinely useful tooling talk, and a Friday that delivered. Here's what stood out from August 10th through the 16th.
The OEE debate that won't die: Over in #digital-transformation, a multi-day argument broke out about whether OEE is even measuring the right thing. It started innocently — someone asked about quick-win digital transformation projects, and another member cited a 5-day Ignition OEE deployment that turned into a full global rollout. Then the pushback landed: if OEE gets calculated inconsistently site to site, what is it actually telling you? The thread never settled on one answer, but the consensus that emerged is worth stealing — consistency of measurement matters more than the formula itself. OEE is a lag indicator for "did we do better than yesterday," not a universal benchmark. One member made the case for Schedule Adherence instead, with a line worth repeating: "OEE was 30%, but we made 120% of what was scheduled." If your plant runs reconfigurable lines, you already know why this gets messy fast.
AI tooling talk got specific: #ai-and-ml had two solid rounds of enterprise LLM comparisons this week — which model to reach for depends more on what you're doing than most people assume. Claude and Claude Code came up repeatedly for reasoning and coding, ChatGPT got flagged as a better reviewer than a first-draft tool, and Claude/Gemini got the nod for graphics work. One member's build was a good example of what this looks like in practice: wrapping Geo SCADA documentation in custom MCP servers so Claude Code can actually work with it directly.
Friday Wins keeps delivering: Friday (Aug 14) was the week's peak activity day, and the wins thread earned it:
- A member built a full home UNS stack from scratch — CODESYS to OPC UA to Node-RED to Mosquitto to Ignition to Perspective. Grassroots proof you don't need an enterprise budget to learn this stack.
- Another landed a new remote full-time role.
- One member presented a ProveIt 2026 recap to their IT/OT group — reportedly "captivated" the room.
- A 3D factory visualization overlaying temperature/humidity sensor data for instant hot-spot/cold-spot detection got shared, then resurfaced again organically the next day — usually a sign it's worth a second look.
Worth checking out: The OpenModScan tutorial (a free Modbus tool) got shared twice this week in #🔗-content-links — good evergreen resource if you missed it both times.
Not in the room yet? Come hang out in the Discord → — that's where the real work gets argued out.
Byte-Sized Brilliance
Shoe Stores Used to X-Ray Your Feet for Fun
Before X-ray imaging became the carefully regulated, FDA-controlled inspection technology behind today's medical scanners and industrial NDT systems (like the ones Teledyne just paid $1.1 billion for), it had a much stranger day job: selling shoes.
From the 1920s through the 1950s, more than 10,000 shoe-fitting fluoroscopes were installed in shoe stores across the United States — with another 3,000 in the UK and 1,000 in Canada at their peak. Customers, often kids, would stick their feet into a wooden cabinet, and a salesperson would flip a switch to blast their feet with X-rays, letting everyone peer through three separate viewing ports to watch the bones wiggle around inside a new pair of shoes.
Here's the part that would never fly today: a 1948 study of 43 machines in Detroit found radiation output ranging from 16 to 75 roentgens per minute — with zero federal oversight and zero shielding for the customer standing directly in the beam. Store clerks who used the machines dozens of times a day fared even worse; documented injuries included dermatitis, and in at least one case, a radiation burn severe enough to require amputation.
It took until 1957 for the first U.S. state (Pennsylvania) to ban the devices — and by 1970, 33 states had followed. Some machines reportedly stayed in use, quietly, into the late 1970s.
The bottom line: the technology now trusted to catch a hairline crack in a jet turbine blade or verify a weld without cutting it open spent its first three decades as an unregulated marketing gimmick to sell saddle shoes to children. Sometimes the difference between a hazard and a precision instrument isn't the technology — it's forty years of learning the hard way.
Let us know how we're doing! https://forms.gle/zSXrKTK9BNZ3BrpXA
Responses