Physicist / RSO Notes · RMS Server

Three topologies, three-tier alarms, and the retention policy AERB expects.

Designing an RMS deployment is three design choices done in sequence — pick the topology (how detectors reach the server), wire the alarm escalation (who sees what, when), and set the archive retention (what AERB inspection reads). This post draws each one.

Topology

Three RMS topologies — which fits which site

Direct-attached

Fit: Small facility (≤ ~8 detectors); single building; short cable runs
Pros: Simplest topology; one cable per detector to the server; no intermediate device to maintain
Cons: Doesn't scale — cable count grows linearly; long cable runs hit RS-485 / Ethernet limits; no local survivability if the central server is down

RDU-aggregated

Fit: Mid-size facility (8–40 detectors); multiple zones (vault corridor + hot lab + theranostic ward + perimeter)
Pros: RDU-02 aggregates 4 detectors per unit; one uplink per RDU to the server; local display and archive at the cluster; survives a brief network outage
Cons: Adds an intermediate device per cluster; requires planning to assign detectors to RDUs cleanly

Federated multi-site

Fit: Hospital network with multiple PET centres / theranostic wards across different sites
Pros: One site-local server per site; sites federate to a central admin console; multi-hospital radiation-safety officer monitors everything from one screen
Cons: Network-level RBAC and audit-trail design adds complexity; needs reliable inter-site networking

Alarm escalation

Three-tier chain with acknowledgement audit

Channel-level threshold: every monitor (gamma, neutron, contamination, stack) has its own warning + action thresholds, set at deployment and stored on the device.
Tier-1 alert: device-level alarm — optical + audible at the monitor; relay output drives a local warning light. Operator at the unit sees it immediately.
Tier-2 alert: cluster-level — the RDU-02 displays the alarm across the cluster (4 detectors); ward / corridor staff see it without going to the affected monitor.
Tier-3 alert: server-level — alarm event streams into the RMS server log; the radiation-safety officer console highlights the alarm; SMS / email notification optional.
Acknowledgement workflow: each tier records timestamp + identity of acknowledger; the audit trail shows who saw the alarm at each tier and what they did. Useful at AERB inspection or post-incident review.

Source: IAEA GSR Part 3 — Radiation Protection and Safety of Radiation Sources; AERB Atomic Energy (Radiation Protection) Rules 2004.

Archive retention

What AERB inspection actually expects

Default policy: 5+ years of archive at the central server for AERB inspection windows. Storage is cheap; AERB inspection retention is a hard requirement.
On-device archive at RDU-02 (5,000 values) and AGM-03 (≥ 180 days) provides outage-window resilience — even if the central server is down, the field record is preserved on each device.
Granularity policy: routine traces at 1-minute average; alarm events at full event timestamp + value. The 1-minute granularity sustains AERB inspection trend review without ballooning the archive.
Export format: time-series CSV / JSON for inspection; PDF summary for the annual radiation-safety committee meeting; both come out of the same server export.