I have received a inquiry if it is possible to integrate SCADA and build an interactive Dashboard from the data coming from SCADA.
Our ERPNext is running in cloud while the SCADA system is local. The SCADA has support following access methods:
How can we integrate SCADA?
If anyone has integrate SCADA please help me.
If MQTT is available then you should use it.
Check out the following:
Personally I would suggest using n8n as middle ware between Frappe/ERPNext and SCADA server.
Check this informative article.
We have been working on an MQTT logger to ERPNext integration with SCADA in mind but it’s not quite ready for release. I’d be happy to show you what we’ve put together and get some feedback. In the SCADA context there’s no such things as a comprehensive solution, you’ve got to adapt to the needs of the plant, which is why it’s hard to call it “done”.
Wifes company ran this in production at a metal finishing plant. Cloud ERP, local SCADA, so the same shape as your setup. Some hard-won opinions.
Don’t store SCADA data in ERPNext. That’s the trap hiding in this thread. MariaDB under Frappe is a transactional ledger, not a historian. Even a modest plant at 1 second resolution generates millions of rows
a month, and the Frappe ORM, permission checks, and version tracking sit on every one of those inserts. The site slows down and your ERP goes down with it.
What worked for us:
A collector service at the plant. A small Python daemon reads the PLCs (we poll directly, but consuming MQTT is the same shape) and writes to a time series database on the same local network. TimescaleDB in our case, InfluxDB also fine. Because the collector is plant-side, a WAN outage loses nothing.
Dashboards come off the historian, not the ERP. Grafana against the time series database. That covers the “interactive dashboard from SCADA data” requirement, and ERPNext is not involved in it at all.
ERPNext receives business events only. Batch complete, quality result, work order state change. Those arrive through the standard REST API or webhooks. A handful of writes per hour instead of per second, and it’s all vanilla surface, no custom app required on the ERPNext side.
On the Frappe MQTT app, yogeshvachhani’s own note tells you the architecture: once the MQTT client needs its own process outside gunicorn, you have a collector daemon. At that point it’s cleaner to run it as a plain systemd service that talks to Frappe over REST than to manage its lifecycle inside the bench.
Agree with tmatteson that there is no comprehensive solution. When we measured our own integration, about 15 percent of it was specific to our plant and could not be generalized. Budget for that instead of
shopping for a connector that claims otherwise.
One security note since your ERP is in the cloud: every connection should be outbound from the plant. Never expose Modbus, OPC, or the SCADA database to the internet please and thankyou 