When every replacement project starts with reverse engineering
When a plant owner replaces an ageing automation system, the new system has to do everything the old one did. Winning that replacement work is a core business for the client, a global leader in industrial process automation. Often it means a competitive replacement: taking out another vendor’s control system and putting the client’s own system in its place.
Scope: this is a programme in progress, not a finished rollout. The work on distributed control systems (DCS) completed a proof of concept and pilot in June 2026, and refinements based on the engineers’ feedback continue. The programme has since shifted its focus to programmable logic controllers (PLCs), where real use is coming. The PLC tool is in a pilot with the client’s designers in October and November 2026. Nothing on this page describes production use across the client’s projects.
Every competitive replacement starts the same way. Before the client’s engineers can rebuild a plant’s control logic on their own platform, they have to work out exactly what the competitor’s system does.
Challenge
Today, working out what a competitor’s system does is manual work. Engineers read through its configuration and logic files and turn them into loop lists, I/O lists and functional descriptions in the client’s own formats. Only then can they agree on what to build, and only after that design the new system.
- The analysis is slow. On a single project it can run to weeks or months. By the client’s own account, even scoping a tender down to I/O level takes about a week.
- It needs scarce expertise. Reading a competitor’s system well takes specialist knowledge, sometimes from outside the company.
- It limits growth. The time spent on analysis caps how many replacement opportunities the client can take on.
The client needs AI that its engineers can check and trust. Whatever the AI produces ends up in a live industrial control system, so a black box is not an option.
Solution
Firemind, as an AWS generative AI partner, built an agentic AI platform for legacy control system migration, on Amazon Bedrock with Anthropic Claude. The platform runs in the client’s own AWS environment, in the EU, and engineers sign in with their existing corporate identity.
Every conversion follows the same four steps. The AI agent does the reading and drafting, and engineers stay in control of every decision.
Legacy configuration and logic files.
A common engineering model, whatever the vendor.
I/O lists, loop lists, functional descriptions, templates.
Each decision traced to its source line.
The work has moved from proof of concept towards production in three stages:
Proven on a legacy DCS
A proof of concept and pilot from February to June 2026 showed the agent could reliably read legacy DCS configuration files and produce loop lists and functional descriptions at the targeted accuracy. The pilot already flagged low-confidence results for human review and mapped how loops depend on each other. By the end of the pilot, the agent was also generating I/O lists and mapping them to the client’s templates.
Refined with engineers’ feedback
Firemind is working with the client’s engineers, following the client’s own project process. On the DCS tool, the work list covers refinements from the engineers’ feedback. It also covers teaching the agent to work out what each device is for, from all of the source data, and to write that into the functional descriptions.
Now focused on PLCs
The same approach now covers PLC-based systems, where conversion volumes are considerably higher and real use is coming. This is now the programme’s main focus. A demo completed in September 2026 produces the I/O list, functional descriptions and import templates from PLC source code. During October and November 2026, the client’s designers are piloting the PLC tool on real project data.
Functional descriptions that are right the first time would considerably ease testing, even operations at the plant later.
Trust was built into the design. The agent shows its reasoning step by step and records where every data point came from, so an engineer can trace each decision back to the exact line of source data it came from. Fixed, rule-based tools produce most of the outputs. The language model is used only where judgement is needed.
Next on the work list is letting engineers correct the agent themselves when it gets a particular kind of case wrong, by updating its skills rather than raising a development request. Each new vendor’s system plugs into the same platform, so what the agent learns on one system carries over to the next.
What the engineers have seen so far
Where the programme stands, November 2026:
Complete
DCS proof of concept and pilot, February to June 2026. PLC demo environment, September 2026.
In progress
DCS refinements from the engineers’ feedback. PLC pilot with the client’s designers, October to November 2026.
The client’s engineers are now reviewing real output from the platform, and their early verdict is positive.
Really great work, quite a big chunk has been taken on and a lot made visible at once.
- Accuracy that holds up on review. The same engineer says the results on the test projects so far “have pretty much hit the mark”, while noting that more test projects could show more variation.
- Scope visible earlier. The platform’s summary page runs through every loop type, counts the I/Os and splits the scope by process area. Scoping a tender down to I/O level by hand takes about a week, so the client sees this page as “a big help for sales”.
- Expertise that can stay in-house. The next step is letting engineers teach the agent directly, so that their knowledge builds up in the platform, not in a development backlog or with outside specialists.
The PLC pilot will be measured against a conversion of a completed project that the client’s designers have already reviewed. Those results, due in December 2026, will give the first hard numbers.
You’ve got this.
