A colleague at SPECOMSYS is developing a SCADA system for machines and buildings using a conservative approach: it runs locally, on our own servers, without a cloud dependency. Today's technologies allow a team familiar with the subject to build a system tailored to a particular site. The first interface is ready, displaying live data from a recycling-plant simulator.
Why local rather than cloud-based?
More control systems are offered as cloud services. They are convenient while connectivity and the provider remain available. A factory, pumping station or building may involve critical infrastructure. A machine should not depend on a distant server, subscription expiry or changes to a provider's terms.
Our approach keeps control close to the equipment. The server and data remain on site, and control commands travel through our own network. The site's control remains in our hands.
What new technologies make possible
Previously, such a system often meant a large supplier, licences tied to tag counts and a predefined template to which the site had to adapt. Today, a small team that understands both machinery and software can build a tailored system: a custom line diagram, tags and alarms, profiles for factories, buildings or stations, a mobile application and dashboards.
Web interface, desktop and mobile clients
The system is designed around a web interface accessible in a browser. Workstations have a graphical application for Windows and Linux, with Mac support as an option. An Android client presents the same screens: readings, machines and alarms with notifications.
Connection security: WireGuard VPN and TLS
The intended approach to remote access is a VPN, specifically WireGuard: a modern protocol with a relatively small codebase. Access is through devices holding the tunnel keys, rather than publishing the control interface directly on the internet. Security also depends on correct configuration and key management.
The system architecture also includes HTTPS/TLS communication with certificates between servers, clients and devices. Where client-certificate authentication is enabled, a valid certificate is required for connection. Certificate management and access permissions remain important parts of the setup.
What the operator sees
- Dashboard — a line diagram showing the hopper, shredder, magnetic separator, optical sorter, mill, baling press, dust extraction and compressor. Material flow is visualised, and a machine in a fault state is highlighted in red.
- Alarms — with priority, timestamp and acknowledgement; who acknowledged an alarm and when is recorded.
- Metering — electricity, water and heat meters together, showing daily consumption and an alert for continuous flow that may indicate a leak.
- Charts and tags — values over time with their source: protocol, address and register.
Remote dashboards with Android TV
One SCADA system, many screens. An ordinary Android TV can serve as a dashboard in production, the loading area or the manager's office. Each screen shows what people there need: readings, machine states and alarms, updated from the same local server without a cloud intermediary.
Communication with equipment
The architecture is intended for equipment commonly found in control cabinets:
- Modbus TCP and RTU — variable-frequency drives, electricity meters, compressors and controllers;
- OPC UA — industrial PLCs and machines with an embedded server;
- MQTT — sensors and IoT devices;
- WAGO PLC — PFC100/PFC200 and CC100, accessing CODESYS variables by name;
- Siemens PROFIBUS DP — SINAMICS and ET 200 through a gateway;
- M-Bus and wireless M-Bus — water and heat meters.
A single site may combine these technologies, as real factories do when machines of different ages and manufacturers share a production line.
A factory, building or station: one software platform
The settings select the site profile: a factory with machines, a building with climate, lighting, access and energy functions, a pumping station or a laboratory. The profile changes the diagram, tags and alarms; the underlying application remains the same.
In development and open to participation
The system is under development. The client interface—what is displayed and how interaction works—is ready. The next step is the server: data collection, history, users and permissions. The described integrations form the intended architecture; the simulator interface does not establish that every function is deployed in production.
Anyone interested can contribute to development and use. Feedback from people working at control panels every day is particularly valuable: what existing systems lack and which devices should communicate first.
