Direct Answer

Should interlocking run locally or wait for the platform? The answer: the more life-critical the action, the closer to the device it must sit. Millisecond-level short-circuit and personnel protection must be hardwired; second-level load shedding and ventilation belong to the local controller; minute-level notifications and work orders belong to the platform. The network carries optimization and visualization, never the job of saving lives.

An industrial park turned its transformer overcurrent tripping into a "remote platform command": the duty room clicked "open," the platform sent the command to the gateway, and the gateway drove the breaker. It sounded smart — until a construction crew cut the fiber. During the 3 minutes of lost communication, one transformer short-circuited internally. Nothing acted locally; the upstream main breaker tripped selectively out of luck, and the transformer was half destroyed. The review reached one conclusion: life-critical actions cannot wait for the platform.

Because:

  • Millisecond actions must be hardwired locally: protection relays have inherent operating times of 5–20 ms; full breaker clearing takes 40–80 ms. The network simply cannot keep up;
  • Second-level actions go to the local controller: load shedding, ventilation, fire interlock complete in 1–5 s, driven by gateway/PLC local logic with no communication dependency;
  • Minute-level actions belong to the platform: notifications, work orders, statistics, optimization — a 30-minute outage changes nothing;
  • Life-critical actions always have top priority: no remote command may override local protection.

Key insight: Interlocking is not "can we do it" but "which layer should do it." Putting critical interlocks on the network layer means building safety redundancy on the least reliable link.

A port substation ran a "double insurance" retrofit: every trip got a hardwired local interlock, while action records were still uploaded to the platform. Six months later, a lightning strike burned out the communications switch — local protection still cleared in 80 ms. The duty room only saw the alarm the next day, but the equipment was unharmed.

1. Three Layers of Interlocking: Response Time Decides Where It Runs

The core constraint of interlocking is time. The time available between event and action determines which layer must execute it.

Layer 1: Local hardwiring (milliseconds)

  • Protection relay inherent time 5–20 ms, plus breaker mechanism 30–60 ms — full chain 40–80 ms;
  • Typical actions: short-circuit tripping, personnel safety (emergency stop, arc-flash protection), busbar undervoltage interlock;
  • Implementation: current/voltage/arc signal → relay → hardwired drive of the trip circuit. No software, no communication, no processor involved;
  • Reliability source: passive, no program, no dependencies — even if the control supply disappears, the trip circuit still operates on capacitor energy storage or mechanical latching.

Layer 2: Local controller logic (seconds)

  • PLC/edge gateway scan cycle 10–100 ms, plus judgment and output delay — action completes in 1–5 s;
  • Typical actions: overload shedding, ventilation start, capacitor switching, automatic transfer switching;
  • Implementation: controller-local program judgment, output relay drive, closed loop within one device;
  • Reliability source: no dependence on the host or network; single-machine autonomy.

Layer 3: Remote platform (minutes)

  • LAN command round trip 10–50 ms; cross-site 50–200 ms; cloud 200 ms–2 s; plus human confirmation — real action is minute-level;
  • Typical actions: remote open/close (after manual confirmation), parameter download, interlock scheme switching, work order dispatch;
  • Implementation: platform → gateway → device. Long chain, many links;
  • Role: optimization and visualization, not protection.

Division of labor: the shorter the available time, the closer to the device the action goes. If hardwiring can do it, never use software; if local can do it, never send it to the platform.

2. Why Hardwiring Cannot Be Replaced by Software

Many people think "relay logic is outdated; a program is more flexible." That mistakes reliability for flexibility.

Four irreplaceable properties of hardwiring:

  1. No software failure surface: no program, no infinite loops, no memory leaks, no upgrade bugs;
  2. No communication dependency: the signal path from CT to relay to trip coil is copper all the way — network and power loss do not matter (provided the supply is independent);
  3. Deterministic delay: the relay's 5–20 ms is a physical property — verifiable and retestable; software delay varies with load and scheduling;
  4. Field verifiable: a test button verifies the whole circuit without any platform being online.

Software's proper boundary: flexible logic (multi-condition combinations, sequencing, trend judgment) belongs to controllers and the platform. But the final action output must have a hardwired fallback — however smart the program is, the output relay and trip circuit must physically exist.

Typical mistake: implementing "overcurrent tripping" as pure software (gateway reads current → judges → commands the breaker). If the controller crashes or communication drops, tripping disappears. Correct approach: protection relay hardwire trips as primary; software records and alarms as auxiliary.

3. Degraded Behavior When Communication Is Lost

Every interlock design must answer one question: what happens when the network goes down?

Normal state: the three layers each do their job — the platform monitors in real time, issues optimization commands, pushes alarms.

Communication-lost state (degradation):

  • Layer 1 (hardwiring): completely unaffected, keeps providing millisecond protection;
  • Layer 2 (local logic): keeps running its program — load shedding, auto-transfer, ventilation continue, they just do not report to the platform;
  • Layer 3 (platform): all remote commands fail; the platform displays "communication lost";
  • Key: degradation is not paralysis — it is returning to local autonomy. That is exactly the purpose of layered design.

Three hard rules for degradation design:

  1. On communication loss, local logic must maintain all existing protection and interlock functions; it must not stop acting because it "did not receive a platform command";
  2. Any interlock that depends on the platform (remote open/close, scheme switching) must be locked out during the outage to prevent half-issued commands from causing misoperation;
  3. After restoration, state syncs automatically, but queued commands from the outage are not executed automatically — they wait for manual confirmation to avoid "after-the-fact" misoperation.

Case: in a data center, the interlock loop was UPS-powered. The communications switch failed for 40 minutes; local auto-transfer logic completed 3 transfers without the data hall noticing. After restoration, the platform synced the 40-minute state curve and operators confirmed no anomaly. Had auto-transfer also been made a platform command, those 40 minutes would have been a disaster window.

4. Priority Between Local Logic and Remote Commands

Priority is not "who has the final say" — it is who sits closer to the safety baseline.

Priority, high to low:

  1. Local protection (relay hardwiring): highest — no command may override it;
  2. Local interlock (controller logic): second — platform commands may not bypass it;
  3. Platform interlock (remote commands): effective only within what local logic allows;
  4. Notifications and records: lowest — they only affect "whether people know."

Conflict-handling principles:

  • Platform issues "close," local logic detects "busbar energized, ground signal present" → refuse and report;
  • Platform issues "shed load," local logic judges "this feeder is carrying a critical load" → prompt for manual confirmation;
  • Platform issues "disable protection" → local must refuse unless dual authorization plus on-site confirmation exists.

Common mistake: giving remote commands priority over local interlocks — e.g., a "remote emergency stop" that bypasses local safety conditions. One misoperation, one platform command, and a whole busbar trips. Correct approach: remote commands must pass local safety validation. Local safety conditions are the gatekeeper for remote commands, not decoration.

5. Power Independence of Interlock Circuits

Interlocks that act fast are meaningless without power. Power independence is the last physical guarantee of interlock reliability.

Three-level power design:

  1. Main control supply: control busbar DC 220 V / DC 110 V — feeds controllers, gateways, indicators;
  2. Interlock actuation supply: independent 24 V DC, or shared with the protection circuit on the control busbar — feeds output relays and interlock coils. Key: the interlock supply must not share a path with communications equipment — a burned-out switch should never disable interlock outputs;
  3. Backup supply: UPS/battery, at least 30 minutes of autonomy (longer for fire-interlock circuits per code), so local logic can still act when communication is lost and the mains are gone.

Anti-pumping and latching: breaker trip coils are designed "short-time energized + anti-pumping" to prevent close/open oscillation; interlock circuits add latching relays so the state holds after action, preventing misreset from supply dips.

Case: a factory retrofit wired the load-shedding output relay and the communications switch on the same 24 V rail. One surge burned the switch's power module — load shedding lost power with it, and two motors burned from un-shed overload. After the retrofit gave interlocking its own supply, the switch could fail freely and shedding kept working.

6. Product Landing: Layered Implementation in the Digital Electrical Intelligent Supervision System

FEXLINK's Digital Electrical Intelligent Supervision System is architected exactly on the three-layer interlocking model:

  • Local protection and hardwired interlocks: an independent physical layer that does not depend on the platform and guarantees millisecond actions;
  • Edge computing gateway (FEXLINK Edge Gateway): handles second-level local logic — load shedding, auto-transfer judgment, ventilation interlock — autonomous when offline;
  • Qianzhi alarm engine: handles minute-level notifications and work orders — graded push, closed-loop tracking, automatic re-send after communication recovers;
  • Tianyan engine (trend-warning algorithms): finds hidden faults early, turning "sudden failures" into "planned repairs" — buying time for local protection, never replacing it.

Design principle in one sentence: the platform makes interlocking smarter; the local layer makes it more reliable. Tianyan detects trends, Qianzhi notifies, the gateway executes local actions, hardwiring saves lives — four layers each doing its own job; if any one fails, the rest keep working.

7. Common On-Site Mistakes

  1. Making tripping a platform software command: fails the moment communication drops. Consequence: protection does not act on fault; equipment burns; upstream selective tripping expands the outage. Correct: protection relay hardwires the trip; the platform only records.
  2. Sharing one supply between interlock circuits and the main controller: a controller fault or supply surge disables all interlocks. Consequence: load shedding and auto-transfer all lose power. Correct: independent interlock supply plus at least 30 minutes of backup UPS.
  3. No degradation strategy for communication loss: defaults to "wait for the platform." Consequence: every interlock stops during the outage window — running naked. Correct: define degraded behavior in advance; local autonomy is the fallback.
  4. Remote commands ranked above local interlocks: one platform miscommand bypasses safety conditions. Consequence: busbar mistrip, mis-synchronizing, personnel risk. Correct: remote commands must pass local safety validation.
  5. No anti-pumping in interlock circuits: close/open oscillation wears the mechanism and oscillates the system. Correct: add anti-pumping relays to trip circuits.

Scope and Limitations

This article discusses layered interlock design principles for industrial and building power distribution, applicable from LV to MV systems. Specific relay selection and circuit parameters follow engineering design and equipment manuals. Fire-interlock circuits subject to mandatory codes must comply with GB 50116 and related requirements. All cases are anonymized (a certain industrial park / port / data center) and do not refer to any specific customer.