SepaIQ: From Raw Process Noise to Enterprise Insight

45-minute video  //

In Sepasoft’s ProveIt! 2026 session, Doug Brandl shows how SepaIQ turns raw, noisy production data into contextualized information that can be trusted across Ignition, Power BI, and enterprise analytics systems.

Learn how SepaIQ acts as a managed data pipeline, enabling you to:

  • Add structure and meaningful context to production data
  • Publish changes to consumers in a controlled way, including new records, updates, and deletions
  • Reduce the need for separate ETL pipelines and ongoing data engineering effort
  • Keep metrics consistent across dashboards, BI tools, and natural language queries

Excited to learn more? Reach out to us to schedule a live demo today!


Read the Transcript

Sepasoft ProveIt! 2026: From Raw Process Noise to Enterprise Insight

Speaker: Doug Brandl, MES Solutions Engineer, Sepasoft

[0:00:04] Hi, thank you for being here. My name is Doug Brandl. I’m an MES Solutions Engineer with Sepasoft. Quick introduction to Sepasoft: we are the premier technology provider for the Ignition platform. We provide MES solutions and modules on the platform solving batch—we have a batch procedure module, a workflow engine, OEE, and track-and-trace. We try to cover the gamut of all the MES activities inside that platform.

[0:00:38] However, today what I’m going to be showing is our SepaIQ platform. SepaIQ is data informatics—think of it as like a contextualized, managed data pipeline. It’s perfect for this space and perfect for ProveIt!. So, let’s go ahead and get into it.

[0:01:01] One of the things that we have to do is identify the problem. It’s a really common problem right now; everybody’s interested in it, especially over the past two years. It’s about being able to effectively leverage AI in manufacturing. The problem really isn’t the models or the maturity of the models; it’s about the data. The data is raw, it’s noisy, and it’s all production data—real-world sensors that jitter.

[0:01:31] A lot of the time, that data doesn’t come with context. You can’t just plug an LLM on top of your raw data because it’s not reliable. Sometimes, in order to do that, you have to build out that appropriate context to get appropriate responses from your language model.

[0:01:49] Effectively, this is a basic drawing of what I’m showing. We have the plant floor layer on the left, which is the virtual factory. We’re leveraging the Enterprise C virtual factory and specifically looking at their bioreactor. You can think of a bioreactor as being like brewing beer. When you’re brewing beer, typically you want to keep the liquids and throw away the solids. In the case of bioreactors, you keep the solids and throw away the liquids.

[0:02:16] They’re exposing the data over MQTT. They have a couple of historians and OPC, and we’re going to consume that data, push it into our analytics engine of SepaIQ, and push that back up into enterprise analytics—into a separate enterprise data lake where we’re going to do reporting. We’re going to leverage language models to do natural language processing, leverage their real power to understand language, and have it interrogate our production layer.

[0:02:50] People typically start in the middle; they assume that data already has meaning. There are a lot of vendors concerned about how to get data from A to B or how to leverage it on the enterprise. That is important, but the most important thing is to give that data meaning and context, and that is hard work. That hard work is what we do.

[0:03:22] If we log into the MQTT Explorer, I want to show you the noise. This sub is the bioreactor on Enterprise C. You’re seeing all sorts of data updating periodically—some points once a second. This is a problem because if you just historize this, you’re going to get terabytes of noise. You’ll get “the temperature was 29.88, then 29.89, then 29.87”. That’s not really insight; that’s just a fog of noise that keeps you from seeing what’s really happening on your process.

[0:04:07] This data is transmitted over MQTT and Sparkplug B. Those are fantastic transmission protocols, but they were never meant to contextualize this data. They solve the transportation problem, not the contextualization problem. This is the gap that SepaIQ fills.

[0:04:37] On the plant floor physical layer, we have our control PLC. Data is being exposed over the MQTT broker as raw noise. What I’m going to do is pull that data into Ignition into the tag provider and condition it. In the Ignition Designer tag browser, I’ve taken all that raw noise and filtered it out. I’ve added deadbanding, I’m calculating moving averages, and I’m providing additional context.

[0:05:29] I’m tracking excursion events and edge detection. These aren’t things that naturally come off of that raw signal. Those raw signals are important to your control systems, but they are not important to people. You have to put insight behind that. I have all this data being pushed into SepaIQ, which is holding the information and performing extra calculations. We’re calculating trends and control efforts off various values like max RPM of an agitator or O2 flow rates. I want to show how we can centralize this to get consistency across the entire organization.

[0:06:44] Looking at our Ignition project, we see a specific batch. This whole process repeats over maybe 28 days. SepaIQ is able to pull and retrieve this information incredibly quickly and display it as charts. We’re calculating high-level metadata: the batch, dissolved oxygen set points, and average deviation. I’m calculating excursion events for dissolved oxygen, temperature, and pH. This tells you how hard your control system is working to maintain that bioreactor.

[0:07:58] SepaIQ allows us to annotate our phases. We’re capturing metadata like when I was feeding the bioreactor, sourcing media, or inoculating. All of this is calculated and stored within SepaIQ. We have a robust connector architecture—we can consume data from an API, Kafka, MQTT v3 or v5, Sparkplug B, and external databases. We can push that data out to Azure Event Grid, IoT Hub, or external databases for the PowerBI report you’re about to see.

[0:09:01] Analyzing this batch data, I noticed a problem. I have one batch record, and immediately afterwards, another batch record ending in a “.0” was created. This is noisy data associated with the shop floor process or OEM equipment you don’t have control over. It’s a nightmare for enterprise-level analysis. You would need a data scientist to figure out all these rules and exceptions, which is a data integrity nightmare.

[0:10:50] We need to stitch this back together. SepaIQ is a contextualized, managed data pipeline. We have context through the ability to draw a picture of a process. It’s “managed” in the sense that I can control updates and who gets my data. In this case, we have a “bad batch” record. I don’t want to delete the data; I need to merge it. We use “report by exception,” recording only values that change.

[0:11:11] Simply, I’m going to wipe out that incorrect batch ID and submit it. You’ll see a propagation of that data back down into Ignition and simultaneously up into a separate enterprise data lake. When I do this, I’m not required to run a separate ETL pipeline or involve a DB admin or data scientist. SepaIQ disperses that data to everyone listening through a publish-subscriber architecture.

[0:12:31] Without refreshing the screen, we look back at the batch list, and we no longer see that bad record. We managed to merge that record off of a simple update within SepaIQ.

[0:13:12] Next, we have a PowerBI report. This shows how the data was pushed up into our enterprise analytics system. This report reads data off a completely separate database, separated out of SepaIQ except for the connector. A technical person on the shop floor can make an update on that raw data, and it propagates up to enterprise BI without any interaction from an IT team member. That’s what I mean by a managed data pipeline.

[0:14:56] You also want the ability to manage calculations. SepaIQ is a nice central repository, often referred to as a UNS. I can set up rules and define calculations like “Control Effort Headroom”. SepaIQ is a back-end tool. You do your display outside of it in PowerBI, Tableau, or Ignition.

[0:15:50] If an engineer wants to know how much “room” is left in a control effort, I can add a calculation. I’ll create a new column in SepaIQ labeled “Control Effort Headroom”. This column flows up into the enterprise data lake used by PowerBI. I didn’t have to reach out to a DB admin or have a SQL expert modify this; I just clicked a couple of buttons to create the new column. I’ll write out a simple script for the calculation: 100 minus the control effort. When I republish, that data propagates both back down to Ignition and up into our data lake.

[0:20:25] We’ve pulled data through MQTT, piped it into Ignition, and passed insights down while passing data up to our enterprise data lake for PowerBI. The next bit is language model integration. It’s not the right way to push all your data to a language model and expect it to do the calculations. The right way is to register your system as a “tool” for these language models. The language model is good at understanding human intent, but it doesn’t know your shop floor data. We instruct it to come to us for that data; I will do the calculations and return them.

[0:21:42] In my Ignition project, I can ask: “I suspect we had an oxygen transfer issue in this batch. Did we see any dissolved oxygen excursions?”. It goes out over the network to ChatGPT. It retrieves the information out of SepaIQ and funnels back a useful response. Language models can hallucinate, but you won’t run into that here because we’ve clearly defined the data that gets returned. If they ask for a batch that doesn’t exist, it’s not going to make up information.

[0:23:17] SepaIQ remains the source of truth, and the language model is the interface. You’re not required to run five or six different reports and combine the data over your lunch break; you can simply talk naturally to the language model. The agent is restricted to our tools for data retrieval; it cannot hallucinate.

[0:26:15] To recap: we started with raw noise, moved to a SCADA contextual layer, and then to SepaIQ, which performs analytics and excursion detection. We have a visualization layer in PowerBI. We solve the hardest problems in manufacturing—real-world things like post-facto updates. If you’re not accounting for those, you cannot trust your data because production is dirty.

[0:27:18] Ultimately, the gap in manufacturing today isn’t data collection; it is data meaning. Every site has historians full of real-time data, but very few have context to it. To leverage AI and language models, you have to tackle the contextualization problem.

[0:28:04] SepaIQ itself is a $20,000 annual subscription plus support. That includes the base platform and the advanced analytics module. We also have the language model integration. If you want to learn more, visit us at https://www.google.com/search?q=sepasoft.com or check out our public demo at https://www.google.com/search?q=demo.sepasoft.com. Thank you guys so much.

About the Speaker

Doug Brandl, MES Solutions Engineer
Doug Brandl is an MES Solutions Engineer at Sepasoft, where he translates real-world manufacturing challenges into clear, industry-specific examples that demonstrate the practical value of Sepasoft software. He also contributes to the evolution of Sepasoft’s platform through strategic solution development that informs long-term product direction. Before his current role, Doug spent nearly a decade at BR&L Consulting, delivering critical data-driven automation solutions that improved operational efficiency across pharmaceutical, oil & gas, and material manufacturing. His work included full FDA validation, MES evaluations, and the design of complex inventory systems using technologies such as Ignition by Inductive Automation.

Scroll to Top