AI in Plant Engineering: the iPad of 2010

Last week I sat in a room in Frankfurt with the German AVEVA E3D community. The topic was AI in plant engineering. The talks were about the technology. The real conversations, the ones in the hallway, were about confusion. I spoke with people who do plant engineering for a living, and each gave me a version of the same answer: we understand this is big, and we can't name the problem it solves for us.

I bought an iPad in 2010 and know the feeling. The device seemed important; what to do with it escaped me. The applications came later, and then the iPad made sense. Plant engineering is holding the iPad right now.

I've spent 30 years in 3D engineering, the last seven bringing CAD into the cloud, and these days I connect that cloud to AI. This article is my snapshot of where AI in plant engineering stands in June 2026, minus the keynote gloss.

The one use case the room could name

One use case did keep coming up, in the talks and in the hallway. Every firm in that room sits on decades of paper: process flow diagrams, the schematic drawings that describe a plant. People want to scan them and have software recognise the symbols and the lines, so that decades of old drawings become data the 3D model can actually use. The need is real and the archives are enormous.

Note the direction of that wish. It feeds the database. I heard no one in Frankfurt talk about the opposite direction: once the data sits in the model, who gets to ask it anything?

Text-to-CAD, the race everyone watches

The industry's AI attention runs the same way. Startups are raising money to teach language models how to design: type a prompt, receive a piping layout. Text-to-CAD. We saw an example in Frankfurt, and it earned its applause. I think this the hardest problem to solve. Designing a plant is the most safety-critical and heavily reviewed part of the whole project. It will be the last place anyone lets an AI work without a human checking each step, and that day sits years away.

E3D users should find this debate familiar anyway. E3D generates its geometry from a database; in a sense the product has been doing text-to-CAD for decades, where engineers type data instead of prompts.

CAD-to-text, the race no one runs

Turn the question around and the prize gets bigger. An E3D model is a database wearing geometry. It knows the pipe lengths, the valve counts, the materials, the weights, the status of each line. The people who need those answers spend their days waiting for them. My estimate from years around these firms: for each person who models in E3D, roughly ten others around the project would benefit from asking the model questions in plain language. The purchaser who needs to know what to order. The planner building work packages. The project manager who wants to know what changed since March.

Today those people have no way in. Looking anything up in the model means becoming an E3D user: a workstation costing thousands, a software license costing more, and some forty hours of training before you can find anything. No firm buys all that for a purchaser who has three questions a week. So the answers stay locked in the model, and the people who need them wait for a designer to have time, or work from yesterday's spreadsheet.

MCP, in one paragraph

The missing piece for CAD-to-text has a name: Model Context Protocol, or MCP. MCP is a fancy word for the connector that lets ChatGPT, Claude or Gemini plug into and "speak" with AVEVA E3D. With it, the purchaser types “which valves in unit 300 aren't ordered yet” into a chat window and gets the answer from the live model. No workstation, no license, no training, no waiting for a designer.

The telltale “no”

In Frankfurt, one presentation went deep into the programming interfaces AVEVA is building for E3D: the technical doors I mentioned, shown slide by slide. So I asked the presenter, a product manager who knew his ground, when AVEVA plans to publish an MCP server for E3D. The answer was a flat no. No roadmap, no plans.

The room's reaction told me as much as the answer. Among the E3D experts present, the term "MCP" did not ring a bell. I know of one customer in that audience that has gone far with AI in plant engineering, and they knew the acronym well. The rest of the room is waiting for the use case, while the plug that would deliver it goes unbuilt.

AVEVA has used the word, in fact. At AVEVA World in Milan this spring, the company announced coming MCP integrations, so that AI assistants can work with data from running plants: sensor readings, measurements, the operations side of the house. Mitsubishi Heavy Industries went ahead and built its own MCP connection for exactly that. The design side, the E3D model and its database, appears in none of it. The operations half of AVEVA is getting a socket; the engineering half stays dark.

What AVEVA does have

Fairness requires a paragraph. AVEVA ships an AI assistant today, and it works the way most enterprise assistants work: documents in, answers out. Feed it manuals and engineering process documentation and it gets good at answering questions about procedures. E3D also carries a machine-learning capability that I found cool to see and limited in reach, AI of an older school. Both are real. Neither connects a language model to the live project model, and that connection is where the use case lives.

Credit also for the guest list. AVEVA brought Tiger Solutions into the conversation, the partner furthest ahead on AI with E3D and already helping AVEVA customers put it to work. Its managing director Tobias Kühnlein was there to contribute. The vendor may not have an MCP server on its roadmap, but it knows who does this well, and it gave them the stage.

The snapshot

That is the snapshot, June 2026. The plant engineering world senses that AI matters and keeps waiting for the use case. The use case has been sitting in the model's database all along: thousands of answers, and a fence around the people who need them. The technology to take the fence down exists today.