Presented by
Happy October 5th, Industry 4.0!
Friday was Manufacturing Day, the one day a year the whole industry collectively says, "Hey, making things is actually pretty cool." If you skipped the plant tours and the career-day pizza, consider this issue your make-up credit.
It's a fitting week for it. The ISM Manufacturing PMI just logged its ninth straight month of expansion, even as the prices index jumped to 77.9 and tariffs keep everyone's blood pressure interesting. Growth is great. Figuring out how to grow without breaking things is the hard part.
This week we're looking at factories that are getting smaller on purpose, a company that decided the best way to get robots is to build the factory that builds the robot parts, and the gap between engineers who expect AI in every tool and those willing to let it make the call. We're also revisiting an assumption you may be leaning on at the edge: that a container keeps things safely separated.
Grab your coffee. Here's what caught our attention:
Containers Aren't a Security Boundary. Here's What to Reach For Instead.
Image: depthfirst
If you run Docker at the edge, here's a research finding worth five minutes: containers share a kernel with the host, so one kernel bug can undo all the isolation you thought you had.
The details:
- Security firm depthfirst published research on CVE-2026-80521, a use-after-free bug in the Linux kernel's AF_UNIX subsystem (the part that handles local communication between processes)
- Containers, and sandboxes like nsjail, Firejail, and Bubblewrap, rely on namespaces, cgroups, and seccomp filters. All of those sit on top of the same shared kernel, so a kernel flaw reachable from inside a container can bypass them
- From there, an attacker can pivot to the host and the other containers on it. On Kubernetes, that can mean the whole node
- The researchers say AI models are speeding up exploit development, and report 5,976 kernel CVEs published by mid-September, with 1,650 of them in August alone
- Their recommendation: run untrusted workloads in microVMs such as Firecracker or Kata Containers, which give each workload its own lightweight kernel
Why it matters: Translation: a container is a great packaging and deployment tool, but it isn't a vault. Plenty of plants now run Docker on edge gateways and IPCs next to the machines they connect to, so a bug at the kernel level matters in the place where IT and OT meet. The good news is this is a design choice you can make, not a reason to rip anything out.
Real-world scenario: Your edge gateway runs a historian connector, a vendor's analytics container, and a third-party dashboard, all on one host. Imagine your maintenance supervisor asking, "Who wrote the code in that analytics container, and what else can it reach if it goes wrong?" Sorting those workloads into trusted (your own code) and untrusted (vendor or community images) tells you which ones deserve their own kernel.
A practical starting point:
- Inventory what runs on each edge host and who built it
- Keep host kernels patched, since the upstream fix for this bug is out
- Pilot a microVM runtime for one third-party workload. The research doesn't dig into performance overhead or operational complexity, so measure both on your own hardware before you roll anything out
The bottom line: Keep using containers for what they're great at, and give your riskiest workloads a kernel of their own.
Microfactories: Small Footprint, Big Rethink
Image: Caracol's additive manufacturing robot, via Manufacturing Dive
What if the answer to long lead times isn't a bigger plant, but a lot of small ones sitting closer to the customer?
The details:
- Microfactories are compact, highly automated sites that build goods on demand or in small batches, using robotics, additive manufacturing (3D printing), digital engineering, AI, and connected production systems
- The push comes from supply chain disruptions and long lead times that have strained just-in-time models
- Manufacturing Dive reports the modular microfactory market is projected to reach $12.8 billion by 2030, with North America holding over 35% of it
- Lower capital requirements mean you can start small and scale as demand grows
- The best fit is high-mix, low-volume work like aerospace, military components, and specialized parts, not mass production
- Caracol, a large-format additive manufacturing company, is pitching networks of distributed factories instead of one monolithic plant
Why it matters: Here's the thing about a network of small factories: every site needs the same data model, the same naming conventions, and the same security posture, or you've built ten islands instead of one network. The hardware is the easy part. The architecture that lets site #7 look like site #1 is where the real work lives. (That's also why the Unified Namespace keeps coming up in our community.)
Real-world scenario: A customer needs 200 custom brackets in two weeks. Instead of waiting on an overseas supplier, a small cell near their facility prints, finishes, and inspects them. Now imagine that cell reporting OEE, quality data, and machine states in the same structure as your main plant, so one dashboard covers both. That's the difference between a microfactory and a science project.
Keep your expectations honest: The market figure is a projection, and the sweet spot is narrow. If your products run in high volume with stable demand, a big optimized line probably still wins on unit cost.
The bottom line: Smaller factories only pay off if they're built to plug into the same data backbone as the big ones.
Amazon Is Building the Factory That Feeds the Robots
Image: The Robot Report
Amazon has built over a million robots. Now it's investing $100 million in a plant to make more of the parts those robots are made of.
The details:
- A new 585,000-square-foot facility in Greenwood, Indiana, will make components for Amazon's fulfillment and robotics operations
- Planned capabilities include advanced fabrication, robotic welding, automated powder coating, and assembly
- About 300 skilled manufacturing and engineering jobs are expected
- Amazon is targeting a 2028 launch, following a similar announcement for Texas in August
- The company already runs one of the largest industrial robotics manufacturing operations in the world in Massachusetts, where it has produced over one million robots
Why it matters: This is vertical integration in its purest form: own the supply chain for the machines that run your operation. For everyone else, the lesson is about dependence. When a critical component or subassembly comes from one supplier with a long lead time, that supplier effectively sets your schedule.
Real-world scenario: Line 2 goes down because a gearbox housing is on a 14-week backorder. You can't build a $100 million plant to fix that. But you can ask which of your top ten spare and wear parts you could machine, print, or stock locally, and which suppliers you'd want a second source for.
Keep in mind: This is a company with enormous scale making a bet for its own needs. Most manufacturers won't replicate it, and the plant won't open until 2028. Treat it as a signal, not a template.
The bottom line: You don't need to build a $100 million plant to learn from Amazon. Know which parts hold your line hostage, and work on them before they fail.
Sponsor Message
Your machines never stop talking. Where does all that data go?
Every sensor, PLC, and machine on your floor writes a new reading every few seconds, all day, every day. That's time-series data, and it piles up fast. Most teams end up in the same spot: keep the history so you can chase down root causes and spot trends, and watch storage costs and query times climb. Or skip the history and lose the context you need when something goes wrong.
Then there's the other trap: adopting a specialized database that nobody on your team knows, and running one more system you have to secure, back up, and keep alive.
Tiger Data's answer is to keep PostgreSQL and build it for time-series. Tiger Cloud is their fully managed Postgres service for time-series workloads, so your team keeps the SQL it already knows. Here's how that maps to the problems above:
- Problem: long history gets expensive. Tiger Data's answer is tiered SSD and S3 storage for "bottomless, cost-efficient" retention, with compute and storage that scale independently
- Problem: the data has to be there when you need it. Multi-AZ clusters with automatic failover, point-in-time recovery, and cross-region backups
- Problem: one more system to learn and lock down. It's Postgres, managed with SQL, a CLI, or Terraform, with SOC 2, HIPAA, and GDPR compliance, always-on encryption, SSO, role-based access control, and audit logging
Tiger Data runs its own query-monitoring product on a single Tiger Cloud service that ingests over 3 trillion metrics a day and stores 3 petabytes of data. Read the blog post to learn more ->
Try it on your own data: new Tiger Cloud accounts get $1,000 in credit, valid for 30 days, with no credit card required. New accounts only.
Create an account and get $1,000 in credit ->
The AI Trust Gap: Engineers Want AI in Their Tools, Just Not Making the Calls
Image: IoT Analytics Research 2026, Design & Engineering Software Adoption Report 2026
Almost everyone expects AI inside their design software. Hardly anyone trusts it yet.
The details:
- IoT Analytics surveyed 120 manufacturers in August for its Design & Engineering Software Adoption Report 2026
- 87% expect AI to become embedded in their core CAD, PLM, and ALM systems
- 86% see the biggest advantage as reducing repetitive work, and 78% expect real value from simulation preprocessing and results interpretation
- Confidence is the problem: the most-trusted use, AI-generated documentation, only reaches 24% high confidence
- For critical decisions like part selection or simulation inputs, high confidence falls to 13-17%
- 81% expect AI to change team structures and engineering skill sets
Why it matters: Translation: people will let AI draft the paperwork before they'll let it pick the part. That's a healthy instinct, and it's a good template for your plant. Start AI where mistakes are cheap and easy to catch, and keep a human approving anything that touches safety, quality, or the bill of materials.
Real-world scenario: Your engineering team uses an AI assistant to write the first draft of a work instruction. A reviewer catches a wrong torque value before it reaches the floor. Now picture the same assistant choosing the fastener on its own. Same tool, very different risk.
Where to start:
- List the AI-assisted tasks in your engineering and quality workflows
- Rank them by cost of being wrong
- Require human sign-off on the top of that list, and track how often reviewers correct the AI. That correction rate is your real trust metric
The bottom line: Trust gets earned task by task, so let the AI earn it on the low-risk work first.
From the Floor: A Week in the Community
From September 25 to October 4, the 4.0 Solutions / Industry 4.0 Discord spent most of its energy on one big question: how do you give an AI agent a map of your plant it can actually trust? The week also had a very practical thread from the field and a Friday Wins post to open things up.
Semantic models for AI agents: In #ai-and-ml, nickn5549 laid out an approach that uses ISA-95 as the backbone, lets an agent propose typed relationships (feeds, measures, limits, causes, part-of), and keeps a human approving each one, with FalkorDB and Cypher underneath. sim_sam3 pointed members toward OWL (Web Ontology Language) resources and has mapped OPC UA Part 5 to OWL. geoffnunan pushed back that validating those ontologies takes trained ontologists, and the thread closed out with the observation that agreeing on shared definitions is as much a people problem as a technical one. Still open.
UNS for South African mining: In #unified-namespace, dylan_iiot asked for context to help explain the UNS to mining operations in South Africa. sparkylarks offered spec docs and recommended a one-line, one-site start with a HiveMQ broker. Small and concrete beats big and abstract.
The PLC tag-list question: In #💬-general, a member asked how to export PLC tag lists into SCADA, tied to platform migrations like Allen-Bradley to Schneider and InTouch to Ignition. If you've done this and have a tool or workflow that worked, jump in. It's still waiting for an answer.
Also worth a look: We asked the room what the first skill should be for a new manufacturing-tech engineer in 2026, and the answers are worth a scroll. A PhD candidate is looking for anonymous survey participants on factory digitalization. And the virtualfactory.online MQTT broker had an outage on Sunday that was fixed the same day. New members this week came from sales engineering, firmware, MES roles bridging IT and OT, and a solo dental-lab integrator, so say hi if you see a new face.
Not in the room yet? Come hang out in the Discord -> -- that's where the real work gets argued out.
Byte-Sized Brilliance
The most influential idea in modern manufacturing may have started with a trip to the grocery store, or at least with the idea of one.
Toyota's Taiichi Ohno started building his pull system in the late 1940s, modeled on American supermarkets, where customers take what they need and shelves get restocked to replace it. According to one lean history, he had only heard of those supermarkets when he started and didn't see one in person until 1956. Early on, the same account says, the information flowing back from the supermarket was written on a scrap of paper. That scrap evolved into the kanban card.
That's the part we love: a system now built into factories worldwide began with paper, a simple rule, and a good analogy from retail. No software, no sensors, just a signal that says "I used one, make one."
It's also the quiet idea behind this week's microfactory story. Make what's needed, close to where it's needed, when it's needed. Eighty years later we're still trying to build factories that behave like a well-stocked shelf, only now the signal is a data point instead of a scrap of paper.
Source: AllAboutLean, "Twenty-five Years after Ohno"
Responses