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.