Episode 47 with Carl Gould

What Ignition 8.3 Means for Industrial Automation's Next Leap

In this episode of Unplugged: An IIoT Podcast, hosts Phil Seboa and Ed Fuentes sit down with Carl Gould, CTO of Inductive Automation, for an in-person conversation recorded in Australia ahead of the Ignition Everywhere event. Carl shares the full arc of Ignition's development, from its origins as a SQL connectivity tool inside a systems integrator to the 8.3 release that is reshaping how large-scale OT systems get built, deployed, and managed.

How IT Tools Became the Foundation of OT Software

When Carl and the team at Inductive Automation started in 2003, the goal was straightforward: take data from an OPC server and store it in a SQL database, then use web technology to build applications around it. "Databases and web technology in 2003 were mature and cost effective and convenient and powerful," Carl explains. "It took some product engineering to make them useful in the OT space, but not all that much, it turns out."

The first product, FactorySQL, solved a gap that existing SCADA and HMI packages had not addressed. Steve Heckman, the owner of the systems integrator where Inductive Automation was born, had projects that required SQL connectivity and nothing on the market could deliver it affordably. That gap quickly expanded. "Everywhere you turned there was just another gap that needed to be filled," Carl says. What set the team apart was a first-principles approach. Rather than studying what competitors did, they focused on solving the problems in front of them using the technology landscape of the day.

Three Principles That Shaped Ignition

Carl distills Ignition's early design philosophy into three words: cost, convenience, and capability. Cost mattered because the price of incumbent SCADA software was pricing entire projects out of existence. "A huge number of projects that got started with Ignition were projects people had in their heads," Carl says. "It would be really cool if we could do this, but the ROI just never penciled out given the cost of the software."

Convenience meant being downloadable and installable in three minutes, a requirement Steve Heckman insisted on from the beginning. It also meant being easy to learn, because the team was already asking PLC programmers to pick up SQL and Python. Adding a steep learning curve on top of that was not an option. Capability came down to flexibility. Carl wanted users to be able to build anything. "Almost every customer comes to me and says, oh, I really love Ignition, but I'm doing something really weird with it," he laughs. "Yeah, you and everybody else."

The 8.3 Release and the Technology Unlock

Ignition 8.3 represents a step change in how the platform handles scale. The core architectural move was deceptively simple: moving all configuration from an internal database to the file system as structured JSON text. "It sounds like a relatively small thing," Carl admits, "but it's like a video game where you unlock one thing and it unlocks all these other things."

That single move enabled Git compatibility, which enabled GitOps workflows, which demanded an open web API for file manipulation, which opened the door to deployment modes for managing dev, staging, and production environments. The release took longer than expected precisely because each unlock demanded the next. "There was a give-a-mouse-a-cookie problem," Carl says. The result is a platform built for orchestration at scale, critical for organizations managing dozens or hundreds of gateways.

One of Carl's favorite features in 8.3 is Perspective's offline mode. "Perspective is sort of like my baby," he says, "and seeing it evolve to go from always connected to offline capable is a big step change." The feature was built for one use case, but customers quickly found unexpected applications for it, which Carl sees as a hallmark of good platform design.

Distributed Architectures and the Scale Challenge

The conversation turns to how factory data requirements have exploded. Where a large SCADA system once meant 20,000 or 50,000 tags, Phil now works with systems handling millions. Carl acknowledges that distributed computing is hard and that the key to doing it well is decoupling. "You want one node to be able to consume the data it needs without knowing where that data has to come from," he explains. This is the strength of pub-sub architectures like MQTT and an area where Ignition's gateway network is evolving.

On the historian front, Ignition 8.3 introduced a new core historian, but Carl is clear that it is only the beginning. "Customers still want to store history data at the edge and then aggregate it at a regional level and then send it all up into the cloud," he says. The future historian architecture will be distributed by design, with value extracted at every level of the organization.

Carl also pushes back on the rigid IT/OT data divide. "I think that's a fictional line," he says. From the early days of building FactorySQL for a winery that needed truck scale data linked to payment systems, Ignition has always been about bridging operational and business data. The problems have not changed in kind, only in degree.

AI as a Means to an End

Carl admits he was late to get excited about AI. "The first iteration, I was like, this is neat, but it's kind of a hokey trick. I'm going to wait out the hype cycle," he says. "I don't feel that way about it anymore." What changed his mind was seeing the product engineering opportunity. Rather than training models, his focus is on context engineering, agentic loops, and system prompts that could help Ignition users build and manage systems more effectively.

The 8.3 architecture turned out to be well positioned for AI in ways the team did not anticipate. Moving configuration into structured text files made the platform Git-compatible, but it also made it AI-compatible. "What started as wanting humans to be able to use Git has now put us into really good position for AI to help humans generate configuration," Carl explains. "It's the exact same move. It just lets you laterally take advantage of a different trend."

Looking ahead, Carl sees AI as a means to an end, not a problem to solve. "We want to use AI to solve the problems of scale," he says. "And the scale has to be solved in big distributed systems." The next three to five years will be about making large distributed OT systems digestible and operable, and AI will be one of the tools that gets them there.

Community, Culture, and What Comes Next

Ignition's growth has been fueled as much by community as by technology. Carl credits the culture at Inductive Automation, describing a team that trusts engineers closest to the code to have the best ideas about how to build things, and those closest to the product to know what to build. "My job increasingly is about creating the conditions under which everybody thrives," he says.

The Ignition Everywhere event in Brisbane reflects that philosophy. Carl sees it as a chance to connect with users in the real world, gather feedback, and build the trust that comes from face-to-face interaction. "A huge part of why the community rallies around us is our culture," he says. "We're just people trying to make cool software that makes your job easier and more fun."

About the Guest

Carl Gould is the CTO and co-founder of Inductive Automation, the company behind the Ignition industrial application platform. He has been building and guiding the product since 2003. Under his leadership, Ignition has grown from a SQL connectivity tool into a comprehensive platform used across industries worldwide for SCADA, HMI, MES, and IIoT applications.

IgnitionInductive AutomationSCADADistributed ArchitectureAI
← Ep. 46: Functional Safety, AI Blindspots, and De...Ep. 48: Containers Without the Complexity: Bring... →