From Platforms to Outcomes: Vatsal Shah on What Industrial AI Actually Needs

From Platforms to Outcomes: Vatsal Shah on What Industrial AI Actually Needs

(Our topic, Our tone, Sponsored by Litmus.io [https://litmus.io] *) Two years ago, roughly every second booth at Hannover Messe had the word “AI” on it. This year the tone has shifted. Less about the layer you buy, more about the outcome you’re trying to deliver. That shift is what Vatsal Shah [https://www.linkedin.com/in/vatsal12/], co-founder and CEO of Litmus [https://litmus.io], came on the podcast to unpack. It’s also the first time he’d talked publicly about how Litmus rethought its own strategy around this idea. Coming from the CEO of one of the more established industrial data platforms, that’s worth paying attention to. (If Litmus is new to you, we covered them earlier with COO John Younes in our Industrial DataOps series [https://itotinsider.substack.com/p/industrial-dataops-5-with-litmus], and wrote about their approach to consolidation in Fighting Entropy [https://itotinsider.substack.com/p/fighting-entropy-how-to-scale-with-litmus].) The $1 trillion question nobody’s asking Here’s the observation that reframed Litmus’ entire 2025 strategy. “If you look at the manufacturing software market, it’s what, like $15 billion? How much is the manufacturing labour market? A trillion dollars plus. It’s a hundred times the software market.” — Vatsal Shah Vatsal’s numbers, not ours, but the ratio is what matters. Every industrial data vendor has been fighting for a share of that small software pie. Meanwhile the vastly bigger prize sits behind a wall we’ve barely tried to cross. To be clear: this isn’t about replacing labour. “In no shape or form can AI replace human workers right now,” Vatsal said, and we agree. We’d add something we’ve argued for a while: in most manufacturing environments today, the constraint isn’t too many operators, it’s not finding enough skilled ones. So the question isn’t “how do we cut headcount?” It’s “how do we make the people we have more effective?” Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work. The Industrial Data Catalog: an old idea, new to the plant floor You can’t get to outcomes without the plumbing. Ask a CIO how many databases they run and you’ll get an answer. Ask a plant leader how many PLCs, which historian versions, which SCADA systems — and past fifty sites, the honest answer is often I don’t know. Data catalogs are a well-worn concept in IT. Vatsal’s claim is that Litmus is the first to bring one to the operational side: every data logger, historian, database, CNC machine — listed on a single interface, for humans on compliance duty and for AI agents as a source of context. Without the catalog, an LLM answering questions on top of plant data was landing at around 85% accuracy in Vatsal’s internal tests. With the catalog providing metadata and context, it jumped to roughly 97%. We haven’t independently benchmarked those figures, but the direction is what everyone building agents on industrial data will run into: garbage in, garbage out — and “garbage” here mostly means no context. The most concrete example in the conversation came from pharma. A C-level exec, asked what burns his people out, named documentation — batch changes, recipe adjustments, quality fixes, all audit-critical, all soul-destroying. Offer them an agent that generates auditor-ready documentation from the underlying data continuously, and the response is “shut up and take my money.” Vatsal was honest about the follow-up: the agent doesn’t yet work to the 30–40% quality bar it needs, because the data, context and integration aren’t there yet. That’s the case for putting the foundation right. Rush the agent, and you’ve got another disappointed pilot. You can check the catalog offering here: litmus.io/litmus-data-catalog [https://litmus.io/litmus-data-catalog]. Stop buying tools. Start buying outcomes. Roughly halfway through, we asked the crystal-ball question: what should the industry actually do next? Vatsal’s answer was refreshingly non-vendor-y for someone running a leading platform: “I’m CEO of one of the leading data technology companies out there, but even I’m thinking we need to get out of platform mindset and start thinking outcomes mindset.” His three non-negotiable foundations: * Own your data. Edge or cloud, but you own it. Don’t hand it back to OEMs. * Document your processes in a way both the next generation of engineers and AI agents can consume. * Cybersecurity. A resilient perimeter isn’t optional. Everything else — the agents, the LLMs, the specific tools — sits on top. This is where most manufacturers go sideways, buying point solutions the way they’ve been buying pumps and valves for fifty years. It’s the same argument for a platformed approach we’ve made elsewhere on scaling [https://itotinsider.com/operational-data-platform/]: without it, you don’t get repeatable value, and adding people or systems slows you down instead of speeding you up. Vatsal turns the tables: how close is IT/OT convergence? Halfway through, Vatsal flipped the script and asked David a question (a genuinely good one 😀): “How close are we to real IT/OT convergence?” Short answer: technically closer than we’ve ever been, organisationally still a long way off. Technical convergence is happening almost everywhere — cloud, containers, DataOps, AI on top. The operational data platform is the layer where IT and OT actually meet. The organisational side is where the speed gets lost. Without collaborative ways of working, no amount of technical convergence delivers the pace the business wants. The lessons from The Phoenix Project [https://itotinsider.substack.com/p/our-mini-itot-book-library-v2] aren’t a one-to-one match with IT/OT, but they’re close enough that they transfer. The pattern Vatsal described — pulling motivated talent from IT and OT into a single Industry 4.0 or Data Transformation team — is one we’ve seen work. It’s also one we’ve flagged with a warning in our upcoming book [http://itotbook.com]: if you’re not careful, that team becomes a third silo. Great internally, disconnected from the plants it’s meant to serve. There are ways around it, but it takes intent. Vatsal’s closing line on this was, we think, exactly right: in a world where every technology is evolving rapidly, adaptability matters more than any specific choice — and that means building a culture where mistakes are treated as learning, not as career-ending events. Final thoughts First: the shift from platform to outcome is genuinely happening — and it’s now coming from platform vendors themselves, not just analysts. That’s a healthier signal than another wave of AI-branded booths. Second: the foundation still matters. Vatsal isn’t saying “skip the platform.” He’s saying stop selling it as if it were the point. The platform is what makes the outcome affordable, repeatable, and scalable. Skip the foundation and the agents don’t work. Skip the outcome and the foundation looks like cost. Own your data. Document your processes. Get the perimeter right. Then figure out which 10% of somebody’s day you can genuinely give them back. Stay Tuned for More! 🙋 Join the [https://itot.academy]ITOT.Academy [https://itot.academy] (new cohort in September) → [https://itot.academy]📘 Pre-order the [https://itotbook.com/]IT/OT Handbook [https://itotbook.com/] (+ claim the bonuses!) → [https://itotbook.com/] Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence. 🚀 See you in the next episode! Youtube: https://www.youtube.com/@TheITOTInsider [https://www.youtube.com/@TheITOTInsider] Apple Podcasts: Spotify Podcasts: Disclaimer: The views and opinions expressed in this interview are those of the interviewee and do not necessarily reflect the official policy or position of The IT/OT Insider. This content is provided for informational purposes only and should not be seen as an endorsement by The IT/OT Insider of any products, services, or strategies discussed. We encourage our readers and listeners to consider the information presented and make their own informed decisions. (*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com [https://itotinsider.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

From Telemetry to Intelligence: What Cumulocity’s IIoT Platform Actually Does

(Our topic. Our tone. Sponsored by Cumulocity [https://www.cumulocity.com/?utm_source=website&utm_medium=link&utm_campaign=ITOT_Insider] *) It’s episode 50 (🎉) of the podcast, and we’re only now getting to IIoT platforms. We sat down with Jürgen Krämer [https://www.linkedin.com/in/juergenkraemer/], Chief Product Officer and Managing Director at Cumulocity [https://www.cumulocity.com/?utm_source=website&utm_medium=link&utm_campaign=ITOT_Insider]. Cumulocity is an IIoT platform with currently more than 25 million connected devices, three billion messages processed per day, and a roster of customers that includes wind energy operators, healthcare devices, and crane manufacturers. Jürgen has been in the IoT and analytics space for over 20 years, which means he’s lived through every wave of the hype cycle and that made our conversation another super interesting one! He also knows that the term “IoT” is notoriously elastic: it gets applied to everything from smart lawnmowers to offshore wind farms, and that ambiguity is a genuine problem when you’re trying to make a technology decision. So time to demystify some concepts around (I)IoT Platforms! IIoT Platform vs Historian We’ve written before about the power of the process historian, and in a typical manufacturing or process plant, the historian is genuinely well-suited. It is designed for high-density time-series capture in a controlled, physical environment where you own the network, the devices are close together, and the architecture is well understood. The moment you move to distributed assets out in the world: in customers’ facilities, on wind farms, on construction sites, in buildings, data centers, and so many others… the picture changes entirely. Because in those cases, you don’t own the network. You have no physical access. You’re managing connectivity across 30,000 turbines in a dozen countries. Firmware updates need to happen over the air. Security is paramount because the device is sitting inside someone else’s infrastructure. That is where the IIoT platform becomes the right tool. As Jürgen puts it: “You need to connect and manage devices you don’t control, in environments you’ve never seen, at a scale that makes manual management impossible.” The M2M → IIoT → AIoT evolution Time for a history lesson! The first wave, around 2010, was M2M (machine-to-machine). It was essentially about connectivity: get the device online, manage the firmware, enable remote access. Useful, but narrow. The IIoT era, roughly 2015 to 2024, added the layer above: dashboards, analytics, edge computing, application enablement. Operations became more optimised, but the work was still largely human-centric. An alert would fire, and a technician would spend hours diagnosing the situation (reviewing log files, cross-referencing documentation, forming a hypothesis). AIoT (what Cumulocity now positions itself as) is the next step. The vision is that the agent does the diagnosis. The technician receives a package: probable bearing failure on Pump 4, replacement part ordered, repair guide attached, shutdown recommended at 14:00, awaiting your approval. The human is still in the loop, but the cognitive labour of diagnosis shifts from the person to the system. We’ve used the term “virtual operator” in previous articles. This is what it could look like in practice (obviously given the availability of enough data, context and the right understanding of the physical reality!) The part most people still skip: Context Context is the most important thing to get right today. It’s the answer to scaling [https://itotinsider.com/operational-data-platform/], it’s the answer to UNS [https://itotinsider.com/the-unified-namespace-uns-explained/], it’s a necessity for AI [https://itotinsider.substack.com/p/industrial-ai-unpacked-introducing]. And thus we’d encourage you to slow down here. Every AI initiative in industry eventually runs into the same wall: raw telemetry is not enough. A value arriving every second from a sensor labelled “Reg_004” means nothing to an LLM, and very little to a human who didn’t configure that tag. Feed that data stream to an AI agent without context, and you will get hallucinations. Jürgen’s team has run this experiment directly [https://www.cumulocity.com/blog/grounding-aiot-in-physical-truth-with-cumulocity/?utm_source=website&utm_medium=link&utm_campaign=ITOT_Insider]: same query, without and with a semantic layer. Without it: plausible-looking KPIs that are simply fabricated. With it: accurate, actionable results (take a look at the result in this video [https://www.cumulocity.com/blog/grounding-aiot-in-physical-truth-with-cumulocity/?utm_source=website&utm_medium=link&utm_campaign=ITOT_Insider]). What does context actually mean here? Jürgen describes three layers: * The first is the system of record — the secure, scalable, mission-critical foundation. This is not exciting, but it is load-bearing. You do not rebuild it from scratch. * The second is the semantic layer. This is what makes industrial data AI-ready. It includes the metadata (is this temperature reading in Celsius or Fahrenheit? what are the normal ranges? when was the sensor last replaced?), the alarm history, the maintenance documentation, and critically: the asset hierarchy. This sensor belongs to this component, which is part of this pump, which sits in this production line, in this plant. Without that hierarchy, you cannot roll up to a meaningful OEE calculation. Without that context, the AI agent is just pattern-matching on noise. * The third layer is the agentic layer — where the AI agents operate, with access to the semantic layer as their knowledge base. There is a parallel here worth naming. We’ve argued for years that industrial DataOps — getting data clean, contextualised, and accessible — is foundational work that pays off for humans first and AI second. Jürgen made the same point: companies that invested in a proper semantic layer years ago, for human operators, got a head start. They built the infrastructure that now, with AI on top, is worth considerably more than they probably expected. Should you vibe-code your own IIoT platform? The short answer is no. The longer answer is: it depends what you mean. David raised the question that’s circulating everywhere right now: with AI-assisted development, can’t we just build our own platform? It’s a reasonable thing to ask, given that a motivated developer with a good LLM can now scaffold something that looks functional in a weekend. The problem is in the word “looks.” The system of record layer — the part that manages tens of thousands of devices, handles over-the-air firmware updates, maintains security compliance in a post-NIS2 world, and operates at 24/7 SLAs — is mission-critical infrastructure. Generating a million lines of code with an AI framework and then being responsible for operating it against contractual uptime commitments is not a viable strategy. As David put it: “Who takes responsibility when things go sideways — not just on availability, but on cybersecurity and supply chain risk?” Jürgen’s distinction is worth keeping: AI-assisted development is genuinely useful at the application layer — building custom dashboards, tuning models on your own data, accelerating vertical use case development. It is not a substitute for a proven platform at the foundation. We’ve watched this cycle before. The Excel macro era, the Access database era, the no-code/low-code era — each one produced a generation of fragile, undocumented tools that someone had to maintain long after the person who built them had moved on. AI-assisted development is the new version of this pattern. Some of what gets built will be excellent. Much of it will become technical debt. The strategic question remains the same as it always has: where does your competitive advantage actually live? (Probably not in having built your own secure, scalable data foundation from scratch) Finding the right use case is harder than it looks Cumulocity has seen hundreds of deployments — predictive maintenance, asset performance management, remote service operations, cybersecurity compliance — and the consistent failure mode is enterprises that start by playing with the technology rather than by defining the business outcome. The right starting point is not “what can we do with AI?” It is “where do we get the most leverage from our investment?” Those are different questions, and the second one is harder to answer without experience. Cumulocity is offering a free one-day consulting workshop for organisations that want to identify their best starting point for an AIoT journey. If you prefer to get your hands on the platform directly, there is also a free trial at cumulocity.com [https://www.cumulocity.com/start-your-journey/free-trial/?utm_source=website&utm_medium=link&utm_campaign=ITOT_Insider]. On our side, the workshop assessment framework we use in our own engagements is available at itotinsider.com [https://itotinsider.com/workshop/]. About Cumulocity Cumulocity is the leading independent AIoT platform, built to bridge the gap between IT and OT. We empower equipment manufacturers and distributed asset operators to securely connect, manage, and extract value from millions of devices on a global scale. From remote device management to industrial DataOps and AI-ready semantic models, Cumulocity provides the mission-critical foundation needed to turn raw telemetry into actionable intelligence; and securely close the loop by executing remote commands, updates, and automated actions right back at the edge. Stay Tuned for More! 🙋 Join the [https://itot.academy]ITOT.Academy [https://itot.academy] (new cohort in September) → [https://itot.academy]📘 Pre-order the [https://itotbook.com/]IT/OT Handbook [https://itotbook.com/] (+ claim the bonuses!) → [https://itotbook.com/] Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence. 🚀 See you in the next episode! Youtube: https://www.youtube.com/@TheITOTInsider [https://www.youtube.com/@TheITOTInsider] Apple Podcasts: Spotify Podcasts: (*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com [https://itotinsider.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

Building a Broker to Learn a Protocol: Andreas Vogler and the Story Behind MonsterMQ

Before we start… We started our 4th IT/OT Academy two weeks ago. Last week and this week we’ll talk about architectural typicals for different use cases, dissect vendor diagrams and step into organizational dynamics with our Cooperation Models. All while our students can network and learn from each other. The next Academy kicks off September 18 and our early bird offer is open. Are you interested in joining? Claim your seat early enough, because the first registrations are already in 🙂 🙋 Join the [https://itot.academy]ITOT.Academy [https://itot.academy] (new cohort in [https://itot.academy]September [https://itot.academy]) → [https://itot.academy] And… have you already pre-ordered our IT/OT Handbook? If so, don’t forget to register to receive your exclusive bonuses. 📘 Pre-order the [https://itotbook.com/]IT/OT Handbook now [https://itotbook.com/] (+ claim the bonuses!) → [https://itotbook.com/] Andreas Vogler [https://www.linkedin.com/in/andreas-vogler/] crossed paths with us at Hannover Messe this year. We all know that moment of “I know your face, I know your name”... and a few weeks later, here we are. Andreas is the Chief Innovation Officer at ETM, the Siemens subsidiary behind WinCC Open Architecture, one of the major SCADA systems in industrial automation. Some years ago, Andreas already built a project called Automation Gateway. A colleague once described it as a collection of open source pieces stitched together and called it Frankenstein of Automation. When he wanted to learn more about MQTT, he built his own broker (which we think is pretty awesome 👍) and the name almost wrote itself: Frankenstein’s monster. MonsterMQ. (If you’re new to MQTT and want a solid grounding before diving in, we covered the protocol in depth in our episode with Kudzai Manditereza [https://itotinsider.substack.com/p/mqtt-vs-opc-ua-with-kudzai-manditereza].) From broker to MQTT+ The first version of MonsterMQ had no UI. Configuration files only because that was the fastest way to get it working. Then AI coding arrived. First GitHub Copilot (hat strange experience of typing a line of code and having it suggest the next one) and eventually more capable agentic tools. Suddenly he could build dashboards. He pulled connectivity features from the Automation Gateway: PLC4X integration for direct PLC communication, database backends (PostgreSQL, MongoDB, SQLite), workflow engines and later also AI agents. What MonsterMQ has become today is probably best described as ‘MQTT+’. A broker, but also a connectivity layer, a persistence layer, and increasingly an intelligent edge runtime. Andreas runs it at home. He has photovoltaic panels, a jacuzzi, a collection of sensors, and an agent inside the broker that checks every 30 minutes whether it makes sense to run the jacuzzi heater. “It tells me: now is a good time.” Practical. A little nerdy. Completely in character. Open source in industrial settings MonsterMQ is fully open source and is not a Siemens or ETM product. It’s Andreas’s project. And that’s where it gets interesting for anyone thinking about adopting it in a production environment. Companies come to him, they like what they see, and then they ask: can I get a support contract? The answer right now is no. That’s not a criticism; it’s just the reality of where the project is. Andreas is aware of it. He’s had those conversations. The EU’s Cyber Resilience Act adds another layer [https://itotinsider.substack.com/p/nis2-and-operations-key-takeaways]: if you’re supplying software to European companies, there are obligations around development process, supply chain and security disclosure, just to name a few. This purely open source side project isn’t yet set up to meet those requirements. None of that makes MonsterMQ unsuitable for exploration or for production grade use, as long as you have the needed skills in-house. But if you’re planning to put it at the heart of a production line, go in with your eyes open. Know what you’re taking on. Vibe coding and the architect problem Andreas has been through the full arc of AI coding (or Vibe coding). Early on, he reviewed every line the AI produced: checking that new code landed in the right class, in the right file, that nothing unnecessary was created. These days, for personal tools like a custom MQTT explorer he built, he doesn’t look at the source code at all. “I don’t care. It works.” But for MonsterMQ itself the standard is different. The human has to remain the architect. Someone needs to know what they want, where it belongs, and whether what was generated is actually doing the right thing. AI coding doesn’t remove the need for expertise. It changes where that expertise matters. You need less of it in the execution and more of it in the direction. The ProveIT demo of WinCC Open Architecture with AI-driven engineering (where an engineer can give the system a Modbus device specification and have it configure the driver automatically) shows where this is heading for industrial software. Faster, yes. But the engineer still has to understand what they’re asking for. Contribute or follow along MonsterMQ is on GitHub. Andreas would welcome contributors. He actually met one of them in person at Hannover for the first time, which he described as “a cool experience.” The project has a demo server, a dashboard, and an active development roadmap. What happens next with MonsterMQ, whether it stays purely open source or evolves into something with commercial backing, is genuinely open. Andreas isn’t ruling anything out. Find Andreas on LinkedIn [https://www.linkedin.com/in/andreas-vogler/] and the project at monstermq.com [https://monstermq.com/]. Stay Tuned for More! 🙋 Join the [https://itot.academy]ITOT.Academy [https://itot.academy] (new cohort in September) → [https://itot.academy]📘 Pre-order the [https://itotbook.com/]IT/OT Handbook [https://itotbook.com/] (+ claim the bonuses!) → [https://itotbook.com/] Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence. Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work. 🚀 See you in the next episode! Youtube: https://www.youtube.com/@TheITOTInsider [https://www.youtube.com/@TheITOTInsider] Apple Podcasts: Spotify Podcasts: This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com [https://itotinsider.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

i3X Explained with John Dyck and Jonathan Wise: One API to Connect Them All?

Before we start… We just started our 4th IT/OT Academy last week. The next one kicks off September 18 and our early bird offer is open. Are you interested in joining? Claim your seat early enough, because the first registrations are already in 🙂 🙋 Join the [https://itot.academy]ITOT.Academy [https://itot.academy] (new cohort in [https://itot.academy]September [https://itot.academy]) → [https://itot.academy] And… have you already pre-ordered our IT/OT Handbook? If so, don’t forget to register to receive your exclusive bonuses. 📘 Pre-order the [https://itotbook.com/]IT/OT Handbook now [https://itotbook.com/] (+ claim the bonuses!) → [https://itotbook.com/] Welcome to another episode of the IT/OT Insider Podcast! We sat down to talk about i3X with John Dyck, CEO, and Jonathan Wise, Chief Technology Architect at CESMII. CESMII is a US not-for-profit consortium, federally funded by the Department of Energy, with a clear mission: make smart manufacturing accessible for all manufacturers, not just the ones with deep pockets and dedicated engineering teams. Fifty projects. One persistent frustration. Before CESMII built anything, they watched. Jonathan’s team ran or supported roughly fifty smart manufacturing projects with US manufacturers — small facilities getting their first sensors connected, large enterprises with decades of automation behind them. Across all of them, the same pattern appeared: interoperability was never designed in. Not because anyone was careless. The mindset across much of the industry — especially in the US, as Jonathan puts it — is to find the problem in front of you, fix it, and move on. The result is what he describes as a patchwork quilt: software layers brought in at different times to solve different problems, never built to work together, often arriving through acquisition. You end up with deeply heterogeneous architectures where nobody — and no system — has a shared understanding of the data. Out of those fifty projects, CESMII extracted valuable lessons. Jonathan’s team identified three things that had to be true for manufacturing data to be genuinely usable across systems. They called them the Smart Manufacturing Imperatives. The first two set the foundation. The third is where i3X comes in. The 3 Smart Manufacturing Imperatives The first imperative is about information modelling. Before data can travel, it needs to mean something. CESMII calls this Information Model Standardisation — an open, standards-based approach to describing manufacturing devices, assets and processes consistently. They’ve built this out through their Smart Manufacturing Profiles [https://www.cesmii.org/technology/sm-marketplace/]: a library of reusable, community-maintained models that give manufacturers a head start rather than asking everyone to start from scratch. Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work. The second imperative is about the platform layer that sits on top of those models. A Contextual Manufacturing Information Platform — a clear set of requirements for what any serious industrial data platform needs to support in order to enable application interoperability. If that sounds familiar, it should: it maps closely to what we’ve described in our own Industrial Data Platform Capability Map [https://itotinsider.substack.com/p/industrial-data-platform-capability-map-dataops-uns-v2]. The capabilities required are broadly the same. The language is different, but the thinking converges. The third imperative is having an open and common API to get to all data in context. Even with shared models and capable platforms, applications still can’t talk to each other if every vendor exposes their data through a different API. i3X — the Industrial Information Interoperability eXchange — is CESMII’s answer to that: an open, common API for manufacturing systems that enables rapid application development, AI deployments, Edge AI, and supply chain integration. We’d go further and say it might also be the answer to something we’ve been asking since we published our Capability Map: what does Capability 7, Data Sharing [https://itotinsider.substack.com/i/171464217/7-data-sharing], actually look like in practice? What i3X is i3X is a vendor-agnostic, open API specification that any manufacturing information platform can implement, regardless of what’s running underneath. It is not a platform. It doesn’t tell you how to build your system. It defines the surface your system needs to expose: typed data, live and historical access through a consistent structure, hierarchical organisation that can expand into a full graph of relationships. Explore CESMII’s interactive visualization here: https://i3x.dev/viz/ [https://i3x.dev/viz/] Explore the API endpoints and try them out yourself via https://api.i3x.dev/v1/docs [https://api.i3x.dev/v1/docs] To make all of this even more accessible, CESMII released i3X Explorer: a free test client that lets you load your implementation and see exactly which functions are covered and which aren’t. Whether you’re a developer building a platform or an engineer specifying a project, it gives you a concrete view of where you stand. At the ProveIT event in Dallas, six vendors demonstrated live interoperability against i3X on the same stage, (Aron Semle from HighByte [https://itotinsider.substack.com/p/aron-semle-on-mcp-agents-and-the] who joined us on the podcast a few weeks ago is one of them). Take a look at the full recording here: Why it matters beyond the API. The bigger picture, as John frames it, is democratisation. If the API is common, a developer or an AI model built against i3X works across any compliant platform. That changes the economics entirely — especially for small and medium manufacturers who can’t afford to rebuild integrations for every environment they deploy into. It also opens up genuine innovation: build once, run anywhere, learn fast, iterate. For manufacturers, the practical message is simple. Start asking your vendors whether they support i3X. If they don’t, ask why. The vendor community has shown it’s willing to move when customers ask for it. The big question for the coming years now becomes: Will this one stick? So…. to be continued 🙂 Extra Resources * i3X specification: https://www.i3x.dev [https://www.i3x.dev] * i3X on GitHub: https://github.com/cesmii/i3X [https://github.com/cesmii/i3X] * Our HighByte episode with Aron Semle: https://itotinsider.substack.com/p/aron-semle-on-mcp-agents-and-the [https://itotinsider.substack.com/p/aron-semle-on-mcp-agents-and-the] Stay Tuned for More! 🙋 Join the [https://itot.academy]ITOT.Academy [https://itot.academy] (new cohort in September) → [https://itot.academy]📘 Pre-order the [https://itotbook.com/]IT/OT Handbook [https://itotbook.com/] (+ claim the bonuses!) → [https://itotbook.com/] Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence. 🚀 See you in the next episode! Youtube: https://www.youtube.com/@TheITOTInsider [https://www.youtube.com/@TheITOTInsider]Apple Podcasts: Spotify Podcasts: This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com [https://itotinsider.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

Kevin Jones from dataPARC on Historians, Industrial Data, Context and a Piece of Black Paper

(Our topic. Our tone. Sponsored by dataPARC [https://www.dataparc.com/] *) Back to our regular schedule, finally. Hannover Messe is in the rear-view mirror, the noise is fading, and we’re easing into one podcast a week again. To get us going, we sat down with Kevin Jones, Director of Partner and Product Strategy at dataPARC [https://www.dataparc.com/], for a conversation that took us all the way back to 1981 — and somehow ended up in a control room in the southeastern US, in the middle of the night, with a piece of black paper taped to a screen. Meet Kevin (and dataPARC) Kevin has spent 26 years at the same company. That’s not a typo. He’s worked on industrial data from every angle imaginable — applications, advanced process control, and for the last two decades, the data architecture and management layer underneath it all. dataPARC itself is a 150-person, globally-distributed team that has stayed laser-focused on one thing: the industrial data stack. Connecting it. Storing it. Moving it between systems. Making it usable for analytics. As Kevin puts it, they’ve thought about expanding into other parts of the business over the years — and consciously decided not to. “That’s been our focus from day one. We just work with industrial plants on their data stack.” In a market where every vendor seems to be drifting into AI, into platforms, into “the data fabric for everything,” that kind of discipline is increasingly rare. And it’s exactly why this conversation went deep on the part of the architecture that gets the least attention but does the most heavy lifting: the historian. Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work. What actually makes a historian It’s tempting, especially if you come from the IT side, to assume any modern database can do the job. Why not just dump time-series data in a data lake and let the hyperscaler figure it out? Kevin’s answer is one we’ll be borrowing for years. “We were once in a meeting where one of the hyperscalers was advertising a use case. They said, ‘we stored 500 values and did all these great things.’ In the industrial world, a big fish tank can have 500 data points.” Industrial historians aren’t dealing with thousands of data points. They’re dealing with thousands to millions of signals, sampled at up to millisecond frequency, retained for years. And — crucially — they’re built so that when an engineer says, give me a thousand tags for the last twelve months because I want to run a machine learning experiment, the answer comes back in seconds, not hours. That’s an architectural decision, not a configuration setting. The other point worth flagging: the cloud-first mindset often forgets the egress side of the equation. Getting data into a cloud system is cheap. Pulling it back out, repeatedly, to compute weighted averages or run rolling analytics, can become eye-wateringly expensive very quickly. From sensor data to semantic layer Time-series data alone isn’t enough, and dataPARC realised this early. Their first commercial historian already had the basics of an asset model — process areas, an organising structure, a way to actually find data without knowing the cryptic tag name. That principle has only grown more important. With AI and large language models entering the picture, the semantic layer is no longer a “nice to have” for analytics teams. It’s the thing that determines whether your AI is repeatable or not. “If we can have a good semantic layer, we can be more repeatable. The use cases are really prevalent and it’s becoming just as important as ever.” Which, of course, brings us to the term that’s been impossible to avoid for the past two years: Unified Namespace. Kevin’s view here is one we share. There’s a broad definition of UNS — having a universal, semantic naming for everything in your enterprise — and a narrower, more branded one that essentially says “MQTT broker on top of your data.” The broad version is foundational. The narrow version, on its own, gives you the most recent value. Useful, but limited. “What happens if there’s a problem with this main flow pump? When did it start? Was it now, or did it start on the night shift? You want to look at your history. So having that universal semantic layer is key — but it should give you the current value and the historical values and be useful when you point a machine learning model at it.” Closing thoughts Forty-something years on from that first homegrown historian at Georgia Pacific, the historian has been declared dead more times than we can count. And every time, it has come back not as a relic but as something more central than before. That’s because, as Kevin put it, all the AI in the world is only as good as the data feeding it. And the data feeding it has to be time-series, has to be contextualised, has to be reliable, and has to be retrievable on demand. Whatever you call that layer of your architecture — historian, time-series database, operational data store — the function isn’t going anywhere. The harder, less glamorous truth is the human one. The piece of black paper taped over a monitor in the middle of the night is a more honest snapshot of where most plants are than any maturity model. Operators have already done the analysis in their heads. They’ve already decided what matters. The job of every IT/OT team is to listen to that, codify it, and build systems that respect it. If your historian is doing its job, the next 2am phone call should be a sign of trust, not failure. About DataParc Founded in 1997, dataPARC [https://www.dataparc.com/] is a comprehensive industrial analytics software suite that helps process manufacturers optimize operations, boost productivity, and drive sustainability. Featuring an enterprise data historian, embedded analytics, and tools for real-time data monitoring, trending, and reporting, dataPARC empowers manufacturers to make smarter, faster decisions that positively impact the bottom line. dataPARC serves customers across the process industries with deployments at thousands of sites globally. Stay Tuned for More! 🙋 Join the [https://itot.academy]ITOT.Academy [https://itot.academy] (new cohort in September) → [https://itot.academy]📘 Pre-order the [https://itotbook.com/]IT/OT Handbook [https://itotbook.com/] (+ claim the bonuses!) → [https://itotbook.com/] Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence. 🚀 See you in the next episode! Youtube: https://www.youtube.com/@TheITOTInsider [https://www.youtube.com/@TheITOTInsider] Apple Podcasts: Spotify Podcasts: (*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com [https://itotinsider.substack.com?utm_medium=podcast&utm_campaign=CTA_1]