UNS Only Solved Half the Problem

Inductive Automation was not built according to any conventional playbook, and that was entirely intentional. Steve Hechtman spent more than two decades as a systems integrator before founding the company in 2003, and the problems he was solving with FactorySQL and FactoryPMI were ones he had lived personally. The first version of FactorySQL was a straightforward OPC-to-SQL data bridge: get the data off the PLC and into a relational database so you could actually do something with it. FactoryPMI followed as a Java-based visualization layer on top of that data. Both were solving a real friction point that every integrator in the industry understood viscerally.

What made those early products unconventional was the underlying philosophy, and it went beyond licensing. At a time when every major industrial software vendor was charging per client, per tag, and per screen, and building on proprietary stacks, Steve built an unlimited-licensing model sold by the server and grounded the entire platform in open IT standards. Using SQL databases for industrial data, leveraging Java for cross-platform compatibility, embracing open protocols rather than building proprietary ones: these were not obvious choices in 2003. The OT world was deeply skeptical of IT practices on the plant floor. But Steve came from the integrator world, and he had lived the pain of systems that couldn't talk to each other, couldn't scale without a purchase order, and couldn't be maintained by anyone outside a narrow specialist community. The industry said the unlimited model wouldn't work. Competitors at trade shows told us we were doomed. But we understood something they didn't: when you remove the economic and technological barriers from a powerful platform built on open standards, you unlock innovation you couldn't have anticipated. Integrators could just say yes to customers. They could experiment. They could build systems that weren't constrained by the fear of overages. That thinking has never changed.

In 2010, consolidating FactorySQL and FactoryPMI under the Ignition platform was driven by a specific technical opportunity and a clear strategic goal. When OPC UA emerged in 2009, it gave us the foundation to become fully cross-platform. We rewrote everything in Java, which meant Ignition could run on Windows, Linux, and Mac from a single codebase. That was genuinely unusual for industrial software at the time, and it removed an entire class of infrastructure constraints for our customers. Ignition 8.3, which we released at ICC in September 2025, is our most substantial release to date. Beyond the architectural improvements to the gateway, historian, and security, it delivered something the industrial software world has largely lacked: first-class support for version control, DevOps workflows, and infrastructure as code. Engineers can now treat Ignition projects the way modern software teams treat any other codebase, with branching, pull requests, and repeatable deployments. Colby described it publicly as a new beginning, not a destination, and the move to an annual major-release cadence, starting with Ignition 2027, reflects the same philosophy: industrial software has to move at the pace of the industry it serves.

The biggest lesson across all of it is that building in industrial software requires a long time horizon and an obsessive commitment to openness. Every time we bet on an open standard, SQL, OPC-UA, MQTT, Python, we were rewarded, and more importantly, so were our customers. Open standards compound in value over time because they allow customers to build on a foundation that is not controlled by any single vendor. Today, we are seeing that play out in customer procurement decisions. Organizations are explicitly refusing proprietary architectures. They want systems that can be maintained by a broad talent pool, extended without vendor permission, and integrated without custom middleware. That is a cultural shift that took years to arrive, and it validates everything we built toward from the beginning.

You've been one of the most visible champions of the Unified Namespace as the single source of truth for the connected factory, but i3X is, in a sense, an admission that UNS only solved half the problem. So what did the industry get wrong about UNS that i3X is now correcting, and given the long graveyard of competing industrial standards, what stops i3X from becoming just another API or endpoint folks migrate to? How do you ensure it drives measurable operational value on the factory floor?

The Unified Namespace was a genuine architectural breakthrough, and we have been among its loudest advocates because it fundamentally changed how people think about data organization in industrial environments. Moving from point-to-point spaghetti integrations to a centrally organized, context-rich data bus was the right answer to a real problem. But it is worth being precise about what UNS solved and what it did not, because those are actually two different layers of the problem.

The industrial data stack has always relied on specialized standards, each doing one thing well. OPC-UA is the right answer at the device level: it provides secure, reliable, semantically rich communication between controllers and SCADA systems. MQTT with Sparkplug is the right answer for publishing context-rich data using report-by-exception, enabling scalable architectures that efficiently connect remote sites and deliver data to the cloud without flooding the network. Each of those standards did its job well. What was missing was a standard for what happens when an application wants to consume that data in full, not just the live values, but the historical record, the object relationships, the type definitions, and the contextual metadata, all through a single interface. That is the gap i3X fills.

i3X is a REST-based industrial interoperability API developed through CESMII alongside many of the leading industrial hardware and software companies in the world. It can discover namespaces, explore object types, query real-time and historical data, navigate relationships, and subscribe to events, all through a single standardized interface. What is significant about that is that before i3X, those capabilities lived in separate places. Live data came through one standard, historical data through a historian API, and relationships and context through a separate data model layer. An application that needed all of it had to build integrations against each of those independently. i3X collapses that into a single surface, which means Ignition can expose the full power of its tag database, including UDTs, alarms, history, and relationships, to any application that speaks i3X. We are not replacing the standards below it. OPC-UA and MQTT still do what they do best. i3X is the application-facing layer that sits above them, making the whole stack consumable.

There is also a supply chain dimension here that does not get enough attention. When industrial data can be shared through a standardized API, it opens the door to structured data exchange across organizational boundaries. A manufacturer sharing operational data with a supplier, an OEM sharing machine data with an end customer, a system integrator delivering a project with standardized handoffs: all of these become dramatically simpler when the consuming interface is a standard rather than a custom integration negotiated on every engagement.

Your question about the graveyard of failed standards is a fair one, and I take it seriously. The reason most industrial standards fail is that they are developed in standards bodies removed from commercial reality, or they get adopted at the specification level but never at the deployment level. i3X avoids those failure modes because every member of the working group is a company with real deployments and real customers who need this to work, and because we are not asking customers to adopt an abstract specification. Native i3X support will be built directly into Ignition. Customers get a working implementation within the platform they already run, which bridges the gap between a standard that exists on paper and one that actually shows up on the factory floor.

The MCP Module is the most important thing we have announced since Perspective, and I want to be precise about why. It is not because AI assistants on the factory floor are interesting as a novelty. It is because MCP is another open standard, and open standards are what allow people to innovate without asking for permission. The more open standards we build into Ignition, the more possibilities the platform unlocks. Every time we add a standard, SQL, OPC-UA, MQTT, Sparkplug, and now MCP, we expand the universe of things customers and partners can build on top of Ignition without requiring custom integration work. Systems just work together. That is the core value proposition, and MCP extends it into the AI layer in a way that no one else has yet.

What we are building does two things. First, it allows Ignition and its modules to expose tags, alarms, historian data, configuration, and design capabilities via the MCP protocol, enabling any AI system to access them in a standardized way. Second, and this is the part that matters most for the ecosystem, it makes Ignition the easiest platform for users and integrators to build their own MCP servers. You define tools, resources, and prompts inside the Ignition Designer, author tools in Python, and connect AI agents to domain-specific OT data and workflows without writing integration code from scratch each time.

The guardrails question is the right one to ask. We are starting with read access to live tags, alarms, and history, and the boundaries around write-back to the PLC are intentional and firm. Industrial safety is not a product feature; it is a constraint we design around, not through. As the agent model matures and as the industry develops the governance frameworks to support it, that boundary will evolve. But we are not going to rush it. The "ABCs" that our team articulated at ICC 2025- accuracy of information, being mindful of data access, and coordinating actions with a human in the loop- reflect how we think about the near-term deployment model: AI as a powerful co-pilot for the operator, not as an autonomous actor.

As for how Ignition stays the platform rather than getting commoditized, the moat is not any single feature. It is the combination of depth in the OT domain, the trust of 69% of the Fortune 100, an integrator network of over 5,000 companies, a free training university with over 10 million video views, and a licensing model that invites experimentation rather than penalizing it. AI companies building industrial applications need a platform that speaks the language of PLCs, historians, alarms, UDTs, and OPC-UA. That is not a generic software problem. That is Ignition's problem to solve, and we have been solving it for over two decades. Ignition 8.3 was explicitly designed with the architectural elements needed to take advantage of MCP and whatever protocols come after it. We are not retrofitting AI onto a legacy platform. We built the foundation with this in mind.

The honest answer is that the partners who turn the Ignition install base into a real distribution channel are the ones who show up with a clear answer to a specific customer problem and a genuine willingness to go deep. The presence in the Technology Ecosystem Program and the listing on our site are earned when you can demonstrate the "better together" story and show how your product works with Ignition in a real deployment. That is the baseline. What separates the ones who build real business from the ones who stay at the logo level is whether they have a real problem to solve and whether they are willing to do the work to solve it for our shared customers.

The program reflects this with its tiered structure: registered, verified, gold, and premier. The higher a partner goes, the more value they deliver to customers, and the more Inductive Automation invests in making that partnership visible and effective. That structure is not bureaucratic; it is how we distinguish depth from surface-level integration.

The ecosystem spans three broad categories. Hardware companies that Ignition runs on, software companies that integrate with Ignition, and companies that have built modules directly on the Ignition platform using our SDK. Each category has a different motion and a different value story, but the common thread is that the best partners in every category are thinking about the customer outcome first.

Sepasoft and Kanoa are good examples of the module model done right. Both built MES capabilities natively on top of the Ignition platform using our SDK, which means their customers get a unified experience rather than a bolt-on integration. Integrators who are already doing SCADA work for a manufacturer can add MES functionality from either company as a natural extension of the project they are already running. The value is clear, and the delivery path is already established. That is what pull-through actually looks like.

On the hardware side, Opto 22 is a strong example of a different kind of depth. They make devices that embed Ignition Edge directly, which means a single piece of hardware can bridge the greenfield and brownfield worlds. A customer deploying at a remote site or retrofitting legacy equipment gets a device that is secure, reliable, and already running Ignition at the edge. The integration story is not something you have to figure out; it is built into the product. That is a fundamentally different conversation than showing up with a data sheet and a logo.

Barbara is another example worth calling out in the software layer. They tackle one of the harder problems in OT deployments: managing and orchestrating Ignition across distributed environments. As customers scale from one site to dozens or hundreds of sites, the operational complexity of managing Ignition instances grows significantly. Barbara brings a DevOps and infrastructure-as-code mindset to that problem, which aligns well with where 8.3 is taking the platform. For startups, the lesson from all of these examples is the same: find the specific place in the Ignition deployment lifecycle where your product creates clear, demonstrable value, build the integrator relationships to deliver it, and earn your way up the program tiers from there.

If i3X and MCP both land the way we are betting, you will see a meaningful compression of integration cost at every layer below the application. Drivers will be faster to build because the data models are standardized. Middleware will face real commoditization pressure because the value of a custom integration layer diminishes when both sides of the integration speak a common protocol. That is not speculation; it is the same dynamic we saw play out with SQL and then with MQTT. The abstraction layers that once required significant expertise to build become utilities, and value migrates to whoever is closest to the outcome.

Where I think people get the analysis wrong is in concluding that this means the platform layer also gets commoditized. The platform that controls the data context, the schema, the security boundary, the historian, and now the MCP interface is not being abstracted away. It is what the application layer depends on. Ignition sits exactly at that layer. We are the system that understands what a Modbus register 40001 actually means, what its historical pattern looks like, what alarm conditions are associated with it, and what the UDT definition implies about the machine it belongs to. An AI agent without that context is useless on the factory floor regardless of how good the underlying model is. That context lives in Ignition.

Looking ahead, we tend to think in one-year increments rather than five because the pace of change in this industry demands it, but there are three clear vectors we are building along. The first is native AI integration in Ignition, both from a developer experience standpoint and from an agent standpoint. People will be building Ignition applications in ways that look a lot like vibe coding today, using AI to accelerate development, generate configurations, and scaffold projects. But they will be doing it on the Ignition platform precisely because of everything that makes Ignition trustworthy: the security model, the support infrastructure, the unlimited licensing, the community. The MCP Module is the foundation of the agent-facing layer, and we will steadily build on it. The second vector is the annual release cadence. Moving to Ignition 2027 and annual major releases makes us meaningfully more agile, and Ignition 8.3 lays the architectural foundation for a lot of what comes next. We will be showing a significant amount of what that looks like at ICC 2026, with announcements about Ignition 2027 features that I think will make clear how seriously we are taking this moment.

The third is the ecosystem. The Technology Ecosystem Program, i3X interoperability, and the integrator network are all working toward the same outcome: an industrial platform that compounds in value because every new partner, standard, and agent capability makes the entire installed base more capable. The long-term bet is that the companies that win in the agentic industrial stack will be the ones that own the trusted data layer on the factory floor, have the community and the integrators to deploy it, and move fast enough on the software side to be the platform AI applications are built on rather than the system they have to work around. That is the position we have been building toward since 2003, and Ignition 8.3 and the MCP Module are the most direct expressions of it to date.