SCADA may appear normal at the operator screen while its background service, communications driver, or controller connection failed to start. On Raspberry Pi, the first decision is not simply Ubuntu versus Debian; identify the operating system’s initialization system and match the SCADA startup integration to it. An Ubuntu installation was reported working normally on a PC, while Raspberry Pi operation under Ubuntu was not demonstrated. Debian 8.5, also identified as Jessie, was reported operating through systemd with only one installation-specific initialization issue.
What is the screen telling you?
Start with the visible symptom. A blank display, stale values, communication indicators, and an application that never opens point to different layers. Do not reinstall the operating system before locating the failed layer.
| Operator observation | Reading to take | Meaning | Next check |
|---|---|---|---|
| No SCADA interface after boot | SCADA process and service state | The application may not have started, or it may have exited during initialization. | Check the initialization system. |
| Interface opens but values are stale | Tag quality, timestamp, and communications status | The display process is running; the failure is probably between the tag database, driver, and controller. | Trace one tag through the driver. |
| Manual start works after login | Difference between the login environment and boot environment | The SCADA package can run, but automatic startup has the wrong account, path, dependency order, or service definition. | Correct boot integration. |
| Application repeatedly stops | Service state and application log at the stop event | Startup supervision, permissions, missing dependencies, or an application fault is terminating the process. | Separate service-manager errors from SCADA errors. |
If the interface and live values both work after a manual launch, keep the existing installation and repair startup. If the process remains running but tags are bad, move past the operating system question and inspect communications.
Which initialization system is actually running?
Read the active initialization system on the target rather than inferring it from a distribution name. The source configuration identifies Debian 8.5, or Jessie, as using systemd. It also describes Ubuntu 14 as using the earlier initialization arrangement. Because “Ubuntu 14” does not identify a complete release, use the running system’s process and service information to decide which startup mechanism applies.
| Setting | Where to read it | Effect on SCADA |
|---|---|---|
| Initialization system | Operating-system process and service information | Determines the correct service definition, enablement method, dependency handling, and log location. |
| SCADA service state | Active service manager | Shows whether startup was attempted and whether the process stayed active. |
| Startup account | SCADA service definition | Controls access to configuration, data, display, and device resources. |
| Working directory and executable path | SCADA service definition | A wrong or relative path can make boot startup fail while an interactive launch works. |
| Dependencies | Service definition and logs | Starting before required storage, networking, or another local component can leave communications unavailable. |
Both systemd and a legacy initialization configuration can start a working SCADA runtime. Use the mechanism native to the installed operating system. On a systemd-based installation, its native service management is the better configuration because startup state, dependencies, restart behavior, and diagnostics remain in one control path.
Does SCADA run when started outside the boot sequence?
Launch the same SCADA executable with the same configuration and intended runtime account used at boot. This check separates application compatibility from automatic-startup integration.
- Confirm that the executable starts and remains running.
- Open the operator interface and inspect one known tag’s value, quality, and update behavior.
- Confirm that the communications driver is loaded and has an active controller connection.
- Stop the test instance cleanly before testing automatic startup, preventing duplicate processes from competing for ports or data files.
If manual launch fails, examine the application log, missing runtime components, file access, and platform compatibility. Changing the service definition cannot repair an executable that does not run on the target. If manual launch succeeds, the operating system can host the application; continue with startup context and ordering.
Is the tag right but the binding wrong?
When the interface opens but data does not move, trace a single displayed value backward. Read the displayed object’s tag binding, locate the tag in the SCADA database, identify its driver address, and compare that address with the live controller variable. A healthy screen process does not prove that the driver or controller session is healthy.
| Check | Pass result | Fail result |
|---|---|---|
| Display-to-tag binding | The object references the intended tag. | Correct the binding; changing Linux cannot repair a wrong reference. |
| Tag quality and timestamp | Quality is valid and the timestamp advances. | Inspect the driver connection and address mapping. |
| Driver-to-controller session | The driver reports an active session and current data. | Check the selected interface, route, controller endpoint, and driver log. |
| Controller variable | The controller value changes as expected. | Diagnose controller logic or field input rather than the SCADA host. |
Test one known changing value instead of relying on a static numeric display. A plausible retained value can hide a dead connection. If tag quality is bad immediately after boot but recovers after a manual restart, return to service dependencies and startup order.
What changes between a PC and Raspberry Pi?
Ubuntu operation on a PC demonstrates that the SCADA software can work with that Ubuntu installation; it does not prove compatibility with an Ubuntu image on Raspberry Pi. The processor build, operating-system image, packaged dependencies, device access, and startup integration must all match the target.
Before migration, record the working host’s executable architecture, required runtime packages, SCADA configuration paths, startup account, driver interfaces, and boot method. On the Raspberry Pi image, verify each item directly. An installer that completes successfully is not a functional test: the executable must start, the driver must open its interface, and live controller data must reach the display.
Choose Debian when the existing Raspberry Pi deployment and service definition are already proven there. Choose Ubuntu when its operator interface or administration model materially reduces maintenance effort and the exact Raspberry Pi image passes the same runtime, driver, reboot, and recovery tests. Interface familiarity improves administration, but it does not resolve binary or driver incompatibility.
How do you correct startup and verify stability?
- Identify whether the running image uses
systemdor the earlier initialization mechanism. - Confirm that SCADA runs manually under the intended runtime account. Resolve application or dependency errors before editing automatic startup.
- Configure automatic startup with absolute executable and configuration paths, the correct account, and access to every required file and device.
- Declare required startup dependencies through the native initialization system. Use service and application logs to distinguish an early dependency failure from a SCADA process fault.
- Reboot the Raspberry Pi. Confirm that only one SCADA instance is running and that the operator interface opens without an interactive login.
- Trace one known changing controller value through the driver, tag database, and display. Verify valid tag quality and continuing updates.
- Repeat controlled restarts and inspect each startup for service failure, delayed communications, stale values, or manual intervention. Treat the installation as stable only when the complete startup and data path repeats correctly.
FAQ
Can I run SCADA on Ubuntu instead of Debian?
Yes, if the SCADA executable, dependencies, drivers, and startup configuration match the target. Ubuntu was reported working normally on a PC, but validate the exact Raspberry Pi image independently.
Does Debian Jessie use systemd for SCADA startup?
The cited Debian 8.5 Jessie installation used systemd. Read the active initialization system on the installed image and configure SCADA through that native service manager.
Can I call the Raspberry Pi SCADA installation stable after it boots?
No. Complete the final verification by rebooting, confirming one running SCADA instance, and tracing a known changing controller value through the driver and tag to the screen with valid quality and continuing updates.