Industrial AI
A plant intelligence portal built from scratch
Process values in the historian, work orders and spare parts in the ERP, quality results in the laboratory system, energy readings in the electrical SCADA. Every answer used to need its own login, export and spreadsheet. One internal portal now brings them together, with a local AI assistant on every page.
Problem
Maintenance, process, stores, planning and quality teams each kept their own reports, rebuilt by hand every week from system exports. Nobody could see a work order, the process conditions around it and the spare part it consumed in one place, and questions that crossed teams took days to answer.
Buying a commercial platform meant a long project, licences per user and data leaving the plant's control. The portal was built in-house instead, one module at a time, each one replacing a spreadsheet someone already maintained.
Design rules
- Read-only at the source. The portal never writes to the historian, the DCS or the ERP. Where the ERP is the system of record, the portal only reads it, so nobody enters data twice.
- Real data only. Screens show measured values and what is derived from them. No targets or KPIs are invented on the page.
- Each module has its own owner and look. Modules share a data layer and a design system but are not copies of each other.
- Bilingual throughout, including the assistant.
Module map
Grouped by the team that owns each module. All modules read from the same data layer and share the assistant.
Inside four modules
What each one replaced, and the technique that made it work.
Stores: live stock and withdrawals
Spare-part stock was an Excel file updated from ERP exports. The module now pulls stock daily from the ERP's web service and discovers the service's operations from its description instead of hard-coding them, which survived several changes on the ERP side.
The ERP offered no movement history through the service, so the module compares each day's snapshot with the last and records the difference as withdrawals and receipts. Weekly and monthly withdrawal summaries go out by email automatically, and catch up if the server was down on the scheduled day.
Parts are mapped to the equipment they belong to from the maintenance team's own parts lists, so a technician can search by equipment tag and see what is in stock.
Maintenance: the ERP as single source
Work orders were entered twice: once in the ERP and once in a team tracker. The module now reads notifications and orders from the ERP and keeps only what the ERP cannot: the weekly plan view, backlog, repair-time statistics and a shutdown list with tag validation against the plant's master tag list. Edit rights are enforced on the server, not only hidden in the page.
Process engineering: design against field
Equipment tags are extracted from the P&ID PDF files, and design flows, temperatures and pressures from the heat and material balance. Each design value is compared with the historian average over a chosen period and flagged when it drifts beyond set limits.
A mass balance view lets engineers define envelopes from measured streams and see where the balance does not close, which usually points to a meter that needs attention.
Plant overview
The portal's front page is a live schematic of the plant, unit by unit, with a detail page for each unit. The page shows only real measurements, and the assistant on the page can answer questions about any value shown.
How it is built and run
Python and Flask, with each module as its own package of routes, templates and data. It runs on an internal server.
Integrations are tested end to end before they reach the server, including against simulated ERP services and with browser-level tests that click through the pages. Each release carries a version stamp visible on the page, so a screenshot shows which version a user is running.
Scheduled jobs keep load on source systems low: pulls run at set times, never on every page view.
Result
Teams see maintenance, stock, process, quality and energy data side by side, in either of two languages. Reports that were rebuilt by hand every week now arrive on schedule. Questions that took days, such as which spare parts a planned shutdown will consume or how a unit is running against its design, are answered on one screen or by asking the assistant.
Stack
Python, Flask, SQL, OPC, SOAP and REST web services, openpyxl for Excel, PyMuPDF for drawing extraction, scheduled jobs, the local assistant described in the assistant case study.