AI builds every screen. The evolution starts from the model.
Most plants run on an HMI application somebody built years ago, and that application holds decisions written down nowhere else: which alarms are critical, what the operator reads at three in the morning, and how the navigation got wired the way it is.
When that application moves, the screens are the easiest part of the job, because AI builds them. The asset is the model the screens are built from. It is the one thing in the project you should own outright, and the way to get it is to read the old application back object by object and land what you find in a typed model. That is where the decisions survive.
I will use one migration to show it. The example is de-identified. We built it from delivered process-plant work, changed every name, identifier and figure, and kept the proportions: 7,553 tags, 126 operator windows, 614 alarms and 556 historized points, read back from a legacy HMI application and rebuilt on FrameworX. What changed on the way across is the subject of this article, and the screens are the smallest part of it.
A typed model
The source application held 7,553 independent tag names, held together by a naming convention and nothing else. The same instrument on the two process trains was two unrelated names, because the area lived in a suffix on the tag and nowhere in a structure.
The delivered solution holds eight equipment templates. A template declares once what a beacon tile, a train meter, a gate actuator or a PID loop has. The eight templates are instanced 516 times, the instances carry 8,063 member tags, and 6,800 of the original 7,553 tags now sit as members of an instance, in a 36-folder plant hierarchy under four branches: plant-wide, train 1, train 2, global.
That is the whole argument. The plant gets a fourth pump, you add an instance. The pump family needs a new member, you edit one template and every instance carries it. In the source, the same change was made tag by tag.
Live vector screens
Once the model exists, the screens are generated from it, with one faceplate shared by every instance of a family.
The 126 source windows became 119 screens, with seven per-area popup families each folded into one. Of the 119, 32 are fully live vector screens carrying 4,412 live animations, and the whole set holds 9,898 elements. Behind the 119 sit 81 logical screens, replicated per area by one rule: a screen is replicated if and only if it reads process data from one train. Everything that is a tool is shared and re-pointed at run time. An engineer reviewing the application reviews 81 logical screens, class by class.
One shared faceplate
The source application aimed its faceplates with 84 indirect tags, and one click could rewrite up to 25 of them to re-point a single window. That is a lot of writes to open one window.
The delivered solution does it with five pointer objects, plus eight more that serve the consolidated popups, 13 in all. Each pointer declares which equipment template it points at, so a click writes one value and the whole member set follows. 236 clicks across the application use that mechanism. The pointers are client-scoped, so two operators can have different equipment open in the same faceplate at the same time. Nothing on the screen was built for that. It comes with the model.
Every construct accounted for
Every one of the source’s 8,940 constructs is either carried onto a delivered mechanism or logged with a named reason. The details the plant depends on came across as they were: 468 of the 614 alarms keep the operator message the plant has read for years, word for word.
The first time the plant changes
The screens are rebuilt from the model, so when the fourth pump is added to the model it opens in the shared faceplate, and nobody draws a window for it. The difference shows the first time the plant changes.
FrameworX is AI-Native by architecture: MCP servers for the Designer, the Console and the Runtime, plus an in-process AI agent spine, ship with the product today. FrameworX ships no model of its own; you connect the model you choose.
See it done in one hour
On 15 October we read a legacy application back and rebuild it live on FrameworX, then walk through what the platform gives you once you are on it. If you bring your own application, the terms are a free assessment, a fixed price, and you pay only if you accept the result.
Register: https://tatsoft.com/webinar-scada-hmi-migration/
Watch the video: https://youtu.be/VSTt4nkqK1s
FrameworX is free to download and develop with: https://tatsoft.com/fx-101/#download
Aim High. Start Simple. Scale Without Limits.