Bringing static P&IDs to life with the Factorian historian MCP server

“Next Frontier” in Process Operations and Commissioning.

Sharing the results of a quick experiment with the Factorian MCP server: a plain PDF of a P&ID goes in, and a live, telemetry-annotated drawing comes back in a single chatbot reply. No tag list, no custom HMI, no SCADA scripting.

Introduction

Every process engineer knows the routine. You have a P&ID open as a PDF on one screen and a historian trend window on the other, and you are flipping between them to answer one simple question: what is this instrument reading right now?

P&IDs are static. The plant is not. Engineers spend a surprising amount of time matching tags on a drawing to tags in a historian, especially during upsets, loop checks and line walks. In our earlier experiments we showed that frontier LLMs connected to the Factorian historian MCP server handle trend analysis, batch tracking, SPC and even PCA-driven outlier detection well. This time we asked a more visual question:

Can the Factorian MCP server bring live data onto a P&ID, with tags mapped automatically?

Experiment Setup: A Drawing, a Chatbot and the Factorian MCP Server

The setup was deliberately simple, with only three moving parts.

• The P&ID drawing. A plain PDF of a hot water storage vessel, V-100, showing its nitrogen blanketing, vent, hot water inlet, outlet to users, heat pad, and the associated pressure, temperature and level instrumentation. This was the only input.
• The chatbot. An LLM-assisted chatbot that reads the drawing and identifies the instruments on it.
• The Factorian MCP server. Maps each P&ID tag to the right historian tag using context, fetches the live values, and returns them so the drawing can be redrawn with the telemetry on it.

The prompt was a single plain-language request:

Here is a P&ID. Fetch the live values of its tags from Factorian and put them on the drawing.

As with our earlier work, the MCP server uses its own secure access token tied to the user’s access privileges in the Factorian historian, so the chatbot only sees the data the user is entitled to see.

How the Tag Mapping Works

The most interesting part of the experiment was what we did not have to provide. There was no tag list and no manual mapping exercise. The MCP server used the context available to it to link each tag on the drawing to the corresponding historian tag.

Where that context is missing, for example when historian tag naming has no obvious relationship to the drawing, you can simply supply your own mapping, from P&ID tag to Factorian tag. The two paths look like this:

• Context exists: the MCP server maps tags automatically. Nothing to supply.
• Context missing: supply a mapping of P&ID tag to Factorian tag.

For reference, this is the mapping used for the six reported instruments in our run. These were demo tags, which is why they are simulated signals.

Results: A Live P&ID in One Reply

In a single reply, the chatbot read the drawing, queried the Factorian historian and returned the V-100 P&ID with live values overlaid directly on the instrument bubbles: pressure, temperature and tank level, each with the right engineering units (bar, °C and litres). All six of six reported tags came back live. The snapshot was taken at about 20:51 IST on 20 October 2026.

The returned drawing also carried a small legend showing the data source, the location, area and asset context, and the unit conventions applied, along with a footer listing every reported tag and its Factorian tag. That makes the result easy to audit: you can see exactly which historian signal sits behind each number on the drawing.

A caution on the output: this was a quick first run, and the generated overlay is not a finished HMI. A few labels overlap parts of the drawing, which is typical of a first pass and the kind of thing that can be tightened with better prompts. The point of the experiment was the workflow, not the polish.

How This Scales to Chemical Unit Operations

V-100 is a simple vessel, but the pattern extends naturally to larger unit operations such as reactors, distillation columns, heat exchanger trains and utility systems.

1. Turnaround and commissioning

Loop checks and line walks are faster when field teams carry a single, live-data schematic on a tablet instead of a paper drawing plus a radio call to the control room.

2. Troubleshooting

During an upset, you no longer need to correlate tags across two screens. You see the process boundaries and the live variables in one spatial view, and can follow up in plain language with trends, comparisons or history for any instrument on the drawing.

3. Legacy uplift

There is no custom HMI development and no local SCADA scripting. The static documentation you already have becomes a dynamic tool, without redrawing anything or starting a new HMI project.

Conclusion: Key Takeaways and Future Potential

The experiment shows a remarkably lightweight way to bridge the gap between process layout and real-time telemetry. Keep the drawings you already have, let the Factorian MCP server map the tags for you (or supply your own mapping when context is missing), and ask for what you want in plain language. The live values land on the drawing.

As with our earlier experiments, these were very preliminary inquiries. With better prompts and refined questions, results can be improved further, saved as reusable prompts, or turned into AI agents that process engineers can run themselves on the shop floor. And because the Factorian edge platform hosts the chatbot interface locally, with token-based access that follows each user’s data privileges, proprietary operational data stays within the bounds of the organization.

What you need is a good data foundation like the Factorian Historian Edge Platform. With it, along with these AI tools, you are only limited by your ideas.