Rapid SCADA drivers can preserve selected runtime state by implementing explicit file persistence in the Communicator Storage directory. Use CommonProps for non-editable shared runtime values, CustomProps for operator-editable settings, and ServerComm when the authoritative state belongs to the Server.
Supported State Mechanisms
| Mechanism | Supported use | Constraint |
|---|---|---|
CommonProps |
Exchange runtime variables between device instances on the same communication line. | Values must be populated again when the line is added; automatic persistence across Communicator or line restarts is not established. |
CustomProps |
Store editable device or connection settings. | Properties are visible and editable, so they are unsuitable for internal state that operators must not change. |
Storage directory |
Store arbitrary driver data across restarts. | The driver must implement serialization, loading, integrity handling, and record ownership. |
ServerComm |
Request server-owned information through the communication line. | The evidence confirms access to ServerComm, but does not define a specific request method for channel archive timestamps. |
The Storage path is available through AppDirs. The evidence recalls that separate Server and Communicator Storage directories appeared in version 5.8, but does not confirm that history; verify the installed release before depending on that version boundary.
Choose the Correct State Owner
Keep configuration and runtime state separate. Place operator-editable connection data in CustomProps. Use CommonProps for internal variables shared between driver instances, such as coordinating two device entries that poll different data from one physical instrument.
Persist only state that must survive a line or Communicator restart. A supported use case is retaining whether a time-synchronization command has already been sent when the device accepts that command only once per day. Without persistence, every restart can cause another attempted synchronization.
Keep archive progress and the last data accepted by the database on the Server. On restart, query the Server through ServerComm and resume from the last server-owned record. This avoids treating a Communicator file as the authority for database state. The evidence does not establish an API for obtaining each channel's last archive timestamp, so confirm that capability in the target installation.
Implement Driver-Owned Persistence
- Define the minimum variables that must survive a restart. Do not serialize all of
CommonPropswhen only a subset is persistent. - Create a stable record key based on an identifier available to the driver, such as the device number. Do not silently key records by communication-line number because the described driver interface cannot obtain that number directly.
- If line identity is required, add it explicitly to the line's user properties and read that configured value. Document that renumbering a line or device requires migration or recreation of its stored record.
- Resolve the Communicator Storage directory through
AppDirs; do not construct or assume its installation path. - Load the saved record during driver or line startup, then copy validated values into
CommonPropsfor sharing between associated device instances. - Save the selected values when the line or Communicator stops. Relevant lifecycle methods named in the evidence include
OnAddedToCommLine,OnCommLineStart,OnCommLineTerminate, andOnCommLineAbort; verify the exact callback contract in the installed driver API before assigning save guarantees to any callback.
Protect Stored-State Integrity
A shutdown callback cannot guarantee execution during power loss or process termination. The evidence specifically warns that interruption while writing can corrupt a single state file and suggests maintaining two files for reliable recovery. It does not define a proven two-file algorithm, so treat this as a design requirement rather than a complete implementation.
At minimum, detect an incomplete or unreadable record and refuse to apply partial values. Where loss of state could duplicate commands or corrupt archive progress, prefer Server-side database state. A Communicator file is appropriate only when its failure behavior is understood and the driver can recover safely.
Verify Restart Behavior
Test the state boundary and ownership, not only successful serialization:
- Run both device entries that share one physical device and confirm that their intended runtime variables are exchanged through
CommonProps. - Stop and restart the communication line. Confirm that the selected variables reload while non-persistent runtime values initialize normally.
- Restart the Communicator and repeat the check. Confirm that internal values remain hidden from operator editing and editable settings remain in
CustomProps. - Change a configured device or line identifier and confirm that the driver either migrates the state record or reports that no matching record exists.
- Present a truncated or invalid state record and verify that the driver rejects it without applying partial data or repeating a protected command.
- For database resume logic, confirm that the driver obtains the authoritative last-saved state from the Server rather than from the local persistence file.
FAQ
Can a Rapid SCADA driver get its communication-line number?
In the interface described by the evidence, it cannot obtain the line number directly. If the driver requires it, store the number explicitly in the line's user properties.
Where should a Rapid SCADA driver save variables across restarts?
Resolve the Communicator Storage directory through AppDirs and implement driver-owned save and load logic there. Persist only selected variables and validate the record before restoring it to CommonProps.
Should database archive progress be stored in CommonProps?
No. Keep the last database-saved state on the Server and access server-owned information through ServerComm; the evidence does not identify a specific API for per-channel archive timestamps.
