Shared Control Room for Multi-Module SMRs: Interlocks Against Wrong-Module Commands

The short version: when several SMR modules are run from one control room, the first error to block is not the operator mistake itself but a command landing on a module other than the one intended. Selecting the module on the HMI screen does not stop that on its own. The basic structure of the interlock has to be end-to-end verification: every command packet carries the target module identifier and an operating authority token, and the module-side controller compares them with its own identity and discards the command on any mismatch.

Safety interlocks come first

Interlocks in a multi-module control room sit on two layers. One is each module’s own reactor protection system, which is never shared between modules and must not be affected by control room operating logic. The other is the operational control layer this article covers. The conditions that layer must hold are below.

• □ Each module’s reactor protection system and manual reactor trip means are independent and hardwired per module, and do not pass through the shared HMI or shared network.
• □ Single operating authority: no two workstations may hold authority over the same system on the same module at once. Authority transfers only through an explicit request-and-accept procedure.
• □ Target module verification: every command includes the target module identifier, and the module-side controller checks it. Commands with a mismatched identifier are discarded and logged.
• □ Shared system concurrency limits: operating phases that draw heavily on shared systems (startup, transfer to shutdown cooling, etc.) are limited in how many modules may be in them at once.
• □ On network loss each module converges to holding its own stable state, not following the last command.
• □ EMO circuits are hardwired per module; shared operating logic only monitors their status.

Ways to stop wrong-module commands compared

How well a misoperation safeguard works in multi-module operation depends heavily on where the check happens. Here is a comparison of blocking at the display, at the network path and at the module controller.

The implication is clear. HMI and network checks lower the probability of error, but only a final check in the module controller that actually executes the command catches defects anywhere upstream in one step. The module controller should read its identifier from cabinet hardware jumpers or fixed inputs, not from a software setting, so a copied configuration file cannot leave two modules with the same identity.

Operating authority and shared system allocation flowchart

1. Authority request: a workstation requests authority by module number and system name.
2. Authority decision: if no one else holds that module and system, issue a token; otherwise wait for the current holder to accept.
3. Command build: include module identifier, system name, token and sequence number in the command.
4. Module-side verification: check hardware identifier, valid token and sequence continuity. On mismatch, discard, alarm and log.
5. Shared system allocation: when entry to a phase such as startup or shutdown cooling transfer is requested, confirm the number of modules already in that phase is below the limit.
6. Authority return: recover the token when operation ends or after a set period without input.

ST pseudocode: module-side command verification

(* I/O MAP - module 3 operational controller, separate from protection *)
(* %I5.0-%I5.3 DI_MODULE_ID_BIT0..3 : cabinet hardware jumper identifier *)
(* %I5.4  DI_NET_A_OK            : control network A healthy *)
(* %I5.5  DI_NET_B_OK            : control network B healthy *)
(* %I5.6  DI_LOCAL_CTRL_SEL      : module local control selected - remote blocked *)
(* %I5.7  DI_RPS_TRIP_STATUS     : module reactor trip status - monitoring only *)
(* %IW500 AI_CMD_MODULE_ID       : target module identifier in received command *)
(* %IW501 AI_CMD_TOKEN           : authority token in received command *)
(* %IW502 AI_CMD_SEQ             : received command sequence number *)
(* %IW503 AI_SHARED_STARTUP_CNT  : modules in startup phase using shared systems *)
(* %Q5.0  DO_CMD_ACCEPT          : command accepted *)
(* %Q5.1  DO_WRONG_MODULE_ALM    : target module mismatch alarm *)
(* %Q5.2  DO_HOLD_STABLE_STATE   : hold stable state mode *)

(* 1. Assemble hardware identifier *)
MY_MODULE_ID := BOOL_TO_INT(DI_MODULE_ID_BIT0)
              + BOOL_TO_INT(DI_MODULE_ID_BIT1) * 2
              + BOOL_TO_INT(DI_MODULE_ID_BIT2) * 4
              + BOOL_TO_INT(DI_MODULE_ID_BIT3) * 8;

(* 2. No remote commands in trip state or with local control selected *)
REMOTE_ALLOWED := NOT DI_RPS_TRIP_STATUS AND NOT DI_LOCAL_CTRL_SEL;

(* 3. Both networks lost - do not follow last command, hold stable state *)
IF NOT DI_NET_A_OK AND NOT DI_NET_B_OK THEN
    DO_HOLD_STABLE_STATE := TRUE;
    REMOTE_ALLOWED := FALSE;
END_IF;

(* 4. End-to-end verification on each new command *)
IF NEW_CMD_RX AND REMOTE_ALLOWED THEN
    IF AI_CMD_MODULE_ID <> MY_MODULE_ID THEN
        DO_CMD_ACCEPT := FALSE;
        DO_WRONG_MODULE_ALM := TRUE;        (* discard and report mismatch upstream *)
    ELSIF AI_CMD_TOKEN <> ACTIVE_TOKEN THEN
        DO_CMD_ACCEPT := FALSE;             (* workstation without authority *)
    ELSIF AI_CMD_SEQ <> LAST_SEQ + 1 THEN
        DO_CMD_ACCEPT := FALSE;             (* sequence gap - suspected resend or duplicate *)
    ELSIF IS_STARTUP_CMD AND (AI_SHARED_STARTUP_CNT >= R_MAX_CONCURRENT_STARTUP) THEN
        DO_CMD_ACCEPT := FALSE;             (* shared system concurrency limit *)
    ELSE
        DO_CMD_ACCEPT := TRUE;
        LAST_SEQ := AI_CMD_SEQ;
    END_IF;
END_IF;

R_MAX_CONCURRENT_STARTUP has to be set from shared system capacity and operating crew staffing, and it differs by design. The sequence check stops a communication resend from executing the same command twice, but without a separate procedure for resynchronizing sequence numbers after a controller restart, valid commands will be rejected too. Protocol latency and resend behavior are items that require field measurement.

Commissioning checklist

• □ Record each module’s hardware identifier jumper setting with photographs and confirm there are no duplicates.
• □ Send test commands deliberately carrying another module’s identifier and confirm they are discarded, alarmed and logged.
• □ Have two workstations request authority over the same system at once and confirm only one gets a token.
• □ Disconnect networks A and B sequentially and together and confirm entry into hold stable state mode.
• □ Confirm requests beyond the shared-system concurrent startup limit are rejected and the reason is shown on the HMI.
• □ Confirm each module’s manual reactor trip works with shared network power removed.

Boundary conditions: when this design is wrong

First, a separate control room for each module. Physical separation greatly reduces wrong-module risk, so end-to-end verification becomes an added defense rather than a requirement. Shared-system allocation interlocks between control rooms become more important instead.

Second, designs with essentially no shared systems. If each module has its own auxiliaries, concurrency limits are unnecessary and the interlock reduces to authority and identifier checks.

Third, staffing where one operator watches several modules at once. The first constraint then is not misoperation but prioritizing during alarm floods, so the alarm priority scheme needs to be designed with the same weight as the interlocks.

The single decision rule: unless the module controller that executes a command directly compares its hardware-fixed identity with the command’s target identifier, the misoperation safeguard in a shared multi-module control room is not complete.