A Linux deployment can lose a calculated pump-runtime value after a host reboot when the current-snapshot directory resides on a tmpfs RAM disk. The value is stored in the snapshot file, so persistence requires physical disk writes. First distinguish a Rapid SCADA Server restart from a complete Linux reboot; the two tests exercise different storage behavior.
Identify the volatile current-snapshot path
The affected installation mounted /etc/scada/ArchiveDAT/Cur as a 10 MB RAM disk:
tmpfs /etc/scada/ArchiveDAT/Cur tmpfs defaults,noatime,size=10m 0 0A RAM disk can retain the current snapshot while Rapid SCADA restarts, but its contents disappear when Linux reboots. Because calculated-channel values are saved in the snapshot file, a host reboot can return the value to zero if that file exists only in volatile storage.
Separate snapshot persistence from channel state
| Observation | Engineering interpretation | Verification |
|---|---|---|
| Value survives a Rapid SCADA restart | The RAM disk remains mounted and retains its files. | Restart only Rapid SCADA and record the channel value before and after. |
| Value becomes zero after a Linux reboot | The current snapshot may have been lost when tmpfs was recreated. |
Reboot Linux and check whether the snapshot file was recreated without the prior value. |
A bit calculated with GetBit() remains set while devices are disconnected |
The retained calculated-channel state may not match the current input mask. The reported input-mask status was 0, while the calculated channel status was 5. |
Reset the input-mask channel and calculated channel through the server generator, then confirm both value and status. |
The configuration includes current, minute, and hourly snapshots plus copies. Available evidence indicates that the calculated-channel value is stored in a snapshot file; it does not establish that every snapshot type restores the current value identically. The reported stuck GetBit() state was cleared only after both the source mask and calculated channel were reset, but no confirmed causal link connects that condition to the Linux reboot loss.
Run a controlled storage test
- Back up the Rapid SCADA configuration and archive data before changing the mount.
- Record the calculated value, its status, the source input-mask value, and the source status.
- Restart Rapid SCADA without rebooting Linux. If the value survives, application restart persistence is working while the RAM disk remains present.
- Reboot Linux with the current-snapshot directory on
tmpfs. If the value resets, confirm that volatile snapshot loss is the differentiating event. - Test persistent storage without the
tmpfsentry and initially leave only one polled device active. This isolates storage performance from device load. - After each test, verify current and archived values in both tables and diagrams; page refresh behavior alone is not proof that the underlying snapshot is absent.
Evaluate persistent-storage behavior
Removing the RAM-disk mount preserved the data, but the tested system then displayed current and archived values intermittently in diagrams and tables. Changing the snapshot write interval between 1 and 5 seconds reportedly made no difference, and restarting Rapid SCADA did not restore consistent display behavior. Restoring the RAM-disk mount and rebooting the host returned display behavior to normal.
Faster RAM-disk I/O than SD-card I/O is a hypothesis, not a confirmed root cause. Linux caching and physical-write settings were also identified as possible influences, but no validated settings or test results are available. Do not assume that version 5.1 adds a separate calculated-channel persistence mechanism; the installation was running 5.0.2, and the evidence does not confirm a version-specific change.
FAQ
Why does a Rapid SCADA calculated channel reset after Linux reboots?
If /etc/scada/ArchiveDAT/Cur is mounted on tmpfs, the snapshot file containing the calculated value is lost during the host reboot. Persisting the value requires writing the snapshot to nonvolatile storage.
Why does the value survive a Rapid SCADA restart but not a Raspberry Pi reboot?
Restarting Rapid SCADA does not clear the mounted RAM disk, while rebooting Linux recreates it without the previous files. Test these restart paths separately before changing channel logic.
Does Rapid SCADA 5.1 fix calculated-channel persistence?
The available evidence only identifies an affected installation running 5.0.2; it does not confirm a persistence change in 5.1. Verify the target version's documented behavior before treating an upgrade as the corrective action.
