Proving UNS with Minimal Costs - Lessons from Systems Integrators | EP06 - The Connected Factory podcast

What’s stopping manufacturers from leveraging their data? High costs, complexity, and IT/OT misalignment. In this episode of The Connected Factory Podcast, Brian Pribe (Mach Controls) and Trent Christopher (4.0 Hero LLC) share their firsthand experiences in system integration, Unified Namespace (UNS), and edge data solutions. They discuss the challenges manufacturers face, why data matters, and how open-source technology is changing the game.

We also explore what’s coming at ProveIt Conference, where Brian and Trent will showcase a hands-on Unified Namespace demo to help manufacturers get started faster and cheaper.

Key Takeaways

Starting a Systems Integration Business & Finding Market Fit

• Brian and Trent transitioned from industrial automation to IT/OT integration.
• Both started with controls engineering, realized the massive gap in industrial data utilization, and built businesses around edge connectivity and data integration.
• Challenges of starting a business in this space: long sales cycles, proving value to manufacturers, and navigating the complexity of industrial networks.
• They found a niche in helping small & mid-sized manufacturers implement Unified Namespace (UNS) without the high costs and time investment of traditional approaches.

Unified Namespace (UNS) as a Manufacturing Data Backbone

• Manufacturers struggle with fragmented, siloed data across 200+ industrial protocols.
• UNS provides real-time visibility by standardizing data from the factory floor to enterprise systems.
• The main benefit is context-rich, structured data that allows manufacturers to scale digital initiatives without costly rework.
• Brian and Trent highlight how they help companies move from concept to deployment faster, reducing integration time and costs.

The MQTT & Kafka Debate: Strengths, Weaknesses, and Best Uses

• MQTT is lightweight and ideal for edge-to-cloud messaging, but it struggles with message persistence, history, and high-throughput streaming.
• Kafka (or Redpanda) provides reliable, scalable event streaming, making it better suited for historical data and enterprise-level data integration.
• UMH’s approach combines the best of both worlds, using MQTT for real-time state changes and Kafka for event-based processing and long-term storage.
• They emphasize that knowing when to use MQTT vs. Kafka is critical for a robust IT/OT architecture.

Why Open-Source & Why UMH?

• Brian and Trent chose UMH over proprietary solutions because of its flexibility, openness, and ease of integration.
• Benthos simplifies data processing by handling protocol conversions and message guarantees efficiently.
• HiveMQ and K3s enable scalable, high-availability deployments even at the factory edge.
• Open-source stacks like UMH offer freedom from vendor lock-in, which is crucial for long-term industrial data strategies.

ProveIt Conference: Hands-On UNS & Edge Integration

• Many manufacturers are hesitant to adopt UNS due to cost and complexity—Brian and Trent aim to change that.
• At Booth #18, they will demonstrate how to get started quickly with pre-configured edge devices, live data streaming, and open-source tools.
• Manufacturers can test UNS themselves, experiencing real-time connectivity without heavy IT overhead.
• The goal: make UNS accessible for small & mid-sized manufacturers, not just large enterprises with big budgets.

Chapters

00:00 Introduction and backgrounds in Industrial Automation
02:57 Discovering Unified Namespace (UNS)
03:44 Manufacturing Data Problems
07:59 Why They Started Their Own Companies
15:52 MQTT vs. Kafka
21:01 Bridging IT & OT
39:16 Prove It Conference
41:04 Making UNS Affordable & Accessible
46:10 Final remarks

Transcript

Jeremy Theocharis:
Hi, welcome to the Connected Factory podcast. With me today are Brian and Trent, system integrators. We'll talk about data ops, open source, interability, and take a sneak peek at what they are preparing for the upcoming Proveit conference. Hi Brian, how are you doing?

Brian Pribe:
Pretty good.

Jeremy Theocharis:
How are you doing, Trent?

Trent Christopher:
I'm doing great. Thanks for asking, Jeremy. I hope you're well.

Jeremy Theocharis:
Trent, please introduce yourself. You're the founder of 4.0 Hero LLC. What is your role?

Trent Christopher:
My background spans 21 years in industrial automation. I started as a system integrator, working as a technician and engineer. I then worked in controls engineering—focusing on programming and integration for a machine builder. Later, I joined a larger manufacturer of automation electronics and worked there as an engineer for six years. I wanted to branch out and help in a more specific way. With 4.0 Hero, I pursued my personal interest in 4.0 solutions and IoT. My focus is on edge data solutions—approaching the problem from the factory floor upward, unlike many who work from the top down.

Jeremy Theocharis:
Brian, what is your role and how did you meet Trent?

Brian Pribe:
I started my company, Mach Controls, as a systems integrator providing the technologies, services, and solutions manufacturers need to optimize operations. We've been in this space since 2020. I got in touch with Trent in spring, and we exchanged ideas on Fork.io solutions in the community. When the Proveit Conference approached, we partnered—Mock leading and Trent assisting with the presentation and demo.

Jeremy Theocharis:
A few days ago, I talked with Matthew Paris, who mentioned he started in this field in 2020. He stumbled upon the topic of the unified namespace then. What was your journey? How did you become involved with the unified namespace in the community?

Brian Pribe:
I think everyone discovered it on YouTube while looking for new developments. Walker posted many videos about the unified namespace, which got our interest. We saw that it allowed manufacturers to track plant floor performance. Manufacturers struggle to collect and analyze data in the context of their business, especially with over 200 protocols on a plant floor. The unified namespace provided visibility into the current state of operations.

Jeremy Theocharis:
You're now a Discord moderator.

Brian Pribe:
I'm officially a Discord mod with the authority to remove spammers quickly. I also serve as the co-lead advisor for the Forteprono community. It's been a rewarding experience to help the community.

Brian Pribe:
I hope to do more this year, especially after Proveit, which has taken up some time.

Jeremy Theocharis:
Trent, as I understand it, you met about a year ago. How did you become involved with the unified namespace topic?

Trent Christopher:
About five years ago—around 2020—when many were first exposed to these topics. Before that, as a machine builder, customers would request that we integrate their equipment into their infrastructure and business systems. We often shied away from these requests because the technology was unfamiliar. Building machines on our own floor and then delivering them left little room for testing, and integration was often passed to the customer. I began to wonder, “What is the better way?” My personal and professional interests led me to search online and explore technologies like MQTT. A coworker even pointed me to a video by Walker Reynolds on the unified namespace.

Trent Christopher:
That video introduced me to the idea that there is a better way—a method that, once you learn the necessary topics, technologies, and applications, becomes reality. That was my introduction to the 4.0 Solutions community.

Trent Christopher:
I've been in the community for five years, engaging in mentorship and mastermind sessions. During that time, I met many people on Discord, including Brian, who frequently participated in discussions. We exchanged ideas long before we became friends.

Jeremy Theocharis:
I believe neither of you has run your own company for long; you're both just getting started. What motivated you to start a new company focused on this?

Trent Christopher:
I started in December.

Brian Pribe:
Thank you.

Trent Christopher:
I'm new to this field, but I saw an opportunity to focus on areas beyond my previous roles, which were centered on controls engineering and equipment development. I noticed a significant gap between controls engineering and IT—the knowledge and skills required in IT were largely unfamiliar to controls engineers. This motivated me to learn more about databases, SQL, OPC UA, and MQTT (much of which I learned from the 4.0 Solutions community). I saw an opportunity to bridge that gap and bring these technologies together, and I recognized that the industry needs this.

Brian Pribe:
Trent started in December, and I started in March 2021, so we've been running our business for nearly four years. Our business has evolved over time, and I imagine United Manufacturing Hub has a similar story.

Brian Pribe:
We began as systems integrators with the goal of speeding up the process from a sales quotation to a finished product. As I developed the business and looked for the next industry trend, I wondered where the next problems would arise.

Brian Pribe:
The biggest issue in the industry is manufacturers and their data. It surprised me that we spend millions on new equipment yet fail to save the generated data. Most machines don’t capture this information. Over time, through mentorship, mastermind sessions, community involvement, and visits to manufacturing plants, I’ve seen that we lack a solid grasp on manufacturing data.

Brian Pribe:
It often depends on the time and software required to get one data point to the needed service. One surprising fact, mentioned during Tulip's operational call with Sesme and the CEO, was that it takes six vendor licenses and 3,000 lines of code to transfer one data point from a sensor to the PLC, then to SCADA, MES, and finally to the ERP system. For multiple machines with thousands of data points, this is impractical. There has to be a better way.

Jeremy Theocharis:
You both have extensive experience with production facilities and control systems, starting from the ground up.

Brian Pribe:
We both started from the ground up. I could talk for hours about our discussions on wiring panels. We began with wiring, and now we're exploring what data means, the underlying technology, databases, historians, and how to connect disparate data sources into a cohesive picture.

Trent Christopher:
Yes.

Brian Pribe:
I believe that in the manufacturing industry—especially for OT and systems integrators—we are just getting up to speed with data and technology. We're at a bridging point as we move forward.

Jeremy Theocharis:
How did you become involved with Yume8? How did you learn about us?

Brian Pribe:
One thing that caught my attention in the community Discord was a public post—either by you or Alex—stating you were fully committed to the unified namespace concept and planned to bring the best product to market. That post was enough for me to keep you on my radar and investigate further: why this stack, what it provides, and all its features. I dove in and was very impressed. For example, your use of Kubernetes and high-availability Docker orchestration in cloud services—techniques common in IT but rare in manufacturing—shows you’re bringing cutting-edge solutions to the OT level. You chose K3S, a high-performance cloud management system for edge devices, which was an excellent start. Then you integrated a broker with HiveMQ—a community edition that scales well for enterprises. I even got that sticker.

Jeremy Theocharis:
For listeners not watching the video, I'm pointing to Shiny—specifically, Shiny‑QB on my laptop.

Brian Pribe:
Yes.

Brian Pribe:
You'll need to send more stickers, especially for the beads.

Jeremy Theocharis:
You'll receive the OPC-in-the-trash-bin sticker for the Proveit conference—many have asked for it. There’s also the unified namespace app sticker, a “We Support Open Source” sticker, and our mascot, Otto.

Trent Christopher:
Thank you.

Brian Pribe:
Soon, everyone at Proveit will have them as well. I want to continue discussing the stack. Every aspect of your approach is phenomenal. Let’s discuss history with the unified namespace—a hot topic. While the unified namespace is often synonymous with the MQTT broker representing current state, we must consider how to store, query, and represent historical data.

Brian Pribe:
This is where architecture plays a role. Traditionally, a unified namespace is demonstrated with a main stack: MQTT (or Mosquitto), Influx, Node‑RED, and Grafana. In those setups, Influx (or Ming) stores historical data by recording topics, but additional pipelines are needed to query the database if an API isn’t provided. Maintaining constant availability of such a historian is challenging. A general-purpose database used as a historian or cache isn’t ideal. With UMH, instead of saving topics directly to the historian, data is bridged to a Kafka broker. This is a game changer because it connects the current state with all historical events. If you need a dedicated API for your MES, you can build a dedicated database for that.

Brian Pribe:
Storing data directly in a database makes retrieval difficult. Kafka captures all events in context, regardless of schema, allowing you to pipe the data into any desired format later. This approach combines the benefits of a high-performance database for historical trends with the ability to archive every event. In our opinion, UMH has built one of the best architectures using top open source software.

Jeremy Theocharis:
To give some background, we built our system because we began as systems integrators—connecting production machines without the burden of managing multiple vendor licenses.

Brian Pribe:
My point is, for a small systems integrator, managing six different vendor licenses is impractical.

Jeremy Theocharis:
That challenge inspired the Ming stack. Over time, we realized we needed to change some components. Mosquitto remains important, but we extended it with Benthos. Grafana stayed, InfluxDB was replaced with TimescaleDB, and Kafka was added. I’m writing an article titled “What Is MQTT? Why Most Explanations Suck and Our Attempt at Fixing Them,” where I delve into the protocol’s low overhead—the very advantage that also limits its capabilities in manufacturing networks. Although manufacturing networks are cable-connected, they require features like history tracking, which MQTT simply does not provide.

Brian Pribe:
MQTT works well for small amounts of data but struggles with streaming, batching, and complex processes such as transactions. Its built‑in mechanisms are minimal compared to, say, a REST API, so you must build extra procedures for transactional communication.

Jeremy Theocharis:
Application protocols are always necessary regardless of the underlying protocol. For safely writing to PLCs, you must define an application protocol. Additionally, MQTT has a theoretical maximum of 65,000 messages in flight (about two bytes each) before messages start dropping—even though in practice, loss begins much earlier. In a typical bridging setup—with edge devices connected to a central MQTT broker—if the connection is disrupted, and you’re sending 1,000 messages per second, you hit that limit quickly.

Brian Pribe:
MQTT is meant to be a message broker for devices, not for high-throughput applications.

Trent Christopher:
It’s designed for low bandwidth. It can pass many packets, but it wasn’t intended for high throughput.

Jeremy Theocharis:
Exactly. With a quality of service above zero (since zero is fire-and-forget), you incur a two‑byte overhead per message. I'm still learning about this. For QoS 1, you can have a maximum of 65,000 messages in transit due to acknowledgement limits—though in practice, the limit is around 1,000 messages, which works for telemetry data such as that from an oil pipeline. Imagine 5,000 sensors across 200–300 miles each sending one data point per second; that’s acceptable. However, high throughput makes acknowledgement challenging for both the server and publisher. You can either send many fire‑and‑forget messages or only a few critical ones—like a car’s remote unlock.

Brian Pribe:
As an IoT protocol, MQTT is designed for small data transmissions over an internet connection.

Jeremy Theocharis:
I spoke with a former MQTT technical committee member who explained that its strength is also its weakness. I discuss this in detail in my article. One advantage of MQTT is its accessibility—almost everyone can use it. In contrast, interacting directly with Kafka is far more complex; I’ve spent evenings staring at a screen trying to work with it.

Jeremy Theocharis:
The same applies to other message brokers like NATS or AMQP. Kafka is complex and often considered a “dumb” message broker that requires a smart client. MQTT, with its smart broker and simple client, makes data transmission accessible—though with limitations.

Jeremy Theocharis:
I always emphasize understanding the trade‑offs of a technology before deciding how to use it. There are many proposals to change the MQTT standard, but I’m not sure significant progress will occur.

Brian Pribe:
You're right—it’s all about trade‑offs. You must build an architecture that meets your needs. MQTT connects many devices on a manufacturing plant floor—from light bulbs to multi‑million‑dollar presses—but it isn’t designed for applications beyond Level 2. That’s where additional infrastructure comes in. How does UMH solve these problems? By combining Kafka and Benthos with MQTT.

Jeremy Theocharis:
Our view is that MQTT remains necessary. It’s simple and can be easily programmed into PLCs. In reality, you have PLCs that speak Modbus, and we’ve discussed Ethernet IP extensively.

Jeremy Theocharis:
You won’t reprogram your PLCs to speak MQTT. Instead, you use a protocol converter—whether self‑made or from a vendor. We use Benthos, and other vendors like Capware offer similar solutions. Our approach combines MQTT with a core backbone of Kafka—or more precisely, Red Panda, a lightweight, single‑binary alternative. We ingest data directly and provide the glue that connects everything.

Brian Pribe:
I appreciate that you chose Benthos. The documentation shows its value in connecting various services.

Jeremy Theocharis:
Benthos is excellent. We discovered it while looking for a solution that required configuration rather than programming. It handles many hidden issues, like commit logic; you can take data from Kafka, process it, and push it back without extra effort.

Brian Pribe:
Regarding quality of service, I believe you only need QoS 1. QoS 2 ensures delivery at least once, but for our purposes, it’s more important that the data gets processed rather than just delivered. MQTT guarantees delivery to the broker, not processing by the application. With Benthos, you can set up separate pipelines—one for posting data to the broker and another for processing it with guaranteed handling. If processing fails, the data is re‑queued. Timing is secondary to ensuring data processing. While technologies like TSN aim to improve timing, our main focus is on robust data processing.

Jeremy Theocharis:
There are still MQTT limitations, but Benthos handles much of the repetitive work.

Trent Christopher:
In controls networks, determinism and high speed are crucial—attributes that higher‑level IT networks often lack. In my previous experience, updates came at a known, high frequency. With event‑based communication like MQTT, the timing is less predictable. However, MQTT’s accessibility is a key strength. Once I learned how to connect and input any data into MQTT—especially using cloud‑based topic subscriptions—it opened up a new world for me. I understand the limitations of MQTT, and I appreciate how UMH bridges MQTT and Kafka to combine usability with robust backend data infrastructure.

Trent Christopher:
I can use protocol converters to connect external devices, then employ Node‑RED with minimal coding to access the database. Everything in between serves as the glue. UMH’s huge value is uniting these components so they work in harmony.

Jeremy Theocharis:
Trent, you've explained why you chose MQTT and UMH, and you're preparing a booth for the Proveit Conference with Brian. What will you be showcasing? What are you offering your customers?

Brian Pribe:
I'll explain what we'll provide at the conference. Currently, the big issue with the unified namespace is the cost and time required to get started. For a manufacturer, instantiating a main stack for a proof of concept can require five to ten IT engineers, take 12 to 18 weeks, and cost between $35,000 and $50,000—covering infrastructure, resource allocation, and device connectivity. This expense makes a proof of concept too costly for many manufacturers. Our goal is to help you get started tracking your plant floor and connecting your machines. With UMH, you get the infrastructure, assets, and hardware needed to demonstrate the value of data to key stakeholders—something many overlook.

Jeremy Theocharis:
Anything to add, Trent?

Trent Christopher:
I am focused on edge connectivity. Without connectivity to equipment, sensors, and devices, automation is extremely difficult. This is a major challenge for many manufacturers, and it has been my focus.

Brian Pribe:
For the Proveit Conference demo, we will showcase three edge devices connected to three panels, demonstrating connectivity with various vendors. This will allow attendees to see what is possible and how they can implement it themselves.

Jeremy Theocharis:
One final question: you will be showcasing three different edge devices and UMH. Can you give a sneak peek of what visitors can expect at your booth?

Brian Pribe:
There will be plenty of stickers. More importantly, the booth will let you try UMH before investing in hardware or programming. The devices, connected IPs, and the on‑premise UMH server will be set up and ready for you to connect and test—demonstrating its value firsthand.

Jeremy Theocharis:
Is there anything else you’d like to highlight? For a manufacturing company in the US interested in UMH, how can they contact you or find you at the Proveit Conference?

Brian Pribe:
You can reach me on LinkedIn, or on Discord, where I’m very active.

Trent Christopher:
Visit my website at 40hero.com. At the Proveit Conference, our booth is located at booth 18 in the top‑left section of the map.

Jeremy Theocharis:
If you're a small or medium manufacturer in the US interested in UMH, check out our booth. We're collaborating closely with Brian and Trent to present UMH. For those in Europe who can't attend Proveit, we will be at Hannover Messe next month on booth G66 in Hall 15. Thank you, Brian and Trent, for your insights. Listeners, I'll include links to Brian and Trent in the description (LinkedIn profiles rather than emails to avoid spam). See you next time.