Direct Answer

"Visible" is only the first step of electrical management. A complete loop is monitor → graded alarm → local actuation → predictive prevention in four stages: monitoring makes things "visible," alarms grade them "by severity," actuation makes them "controllable," and prediction makes them "foreseeable." The key division of labor in this loop: the edge performs millisecond-level actuation (local relays, tripping, load shedding), and the cloud performs trend prediction (remaining life, limit-breach forecasting, maintenance planning); only when both sides cooperate does "finding a problem" upgrade into "controlling the problem + preventing the problem." The sign of a mature loop is not how fast alarms ring, but that most hidden dangers are absorbed by actuation or planned maintenance before they become incidents — this is the value of "from visible to controllable."

1. Why Electrical Management Needs a Closed Loop

Many enterprises' electrical monitoring systems stop at the "visible" stage: measurement data on the platform, alarms pushable, reports exportable — but the field still depends on people to respond. The result: an alarm arrives, the duty operator judges, calls, runs to the site, handles manually — the window from discovery to handling is measured in hours, while electrical faults go from anomaly to incident in minutes or even seconds (overcurrent, arcing, insulation breakdown). No matter how fine the monitoring, if the handling chain is broken, the system's value is halved.

The essence of a "closed loop" is bringing every link from "finding a problem" to "solving it" into system design: who senses, who judges, who handles, who prevents — each with a clear carrier and response time. The four stages (monitor, alarm, actuate, predict) answer four questions of electrical management:

  • Monitoring answers "what is happening now";
  • Alarm answers "is it important, does it need handling";
  • Actuation answers "can it be controlled automatically";
  • Prediction answers "what will happen next, and when to maintain."

Missing any stage breaks a section of management: monitoring without alarms means data no one reads; alarms without actuation means response depends on running people; actuation without prediction means fighting fires forever. This is the substance of "from visible to controllable" — turning passive response into proactive management.

2. The Four Stages: Inputs and Outputs

Looking at the four stages separately, each has clear inputs, outputs, and judgment:

Monitoring (sensing): inputs are electrical and non-electrical quantities (current, voltage, temperature, residual current, harmonics, partial discharge); outputs are continuous, clean, timestamped measurement data. The key is "measurable and measured accurately": coverage of critical circuits, accuracy meeting requirements, and data that does not gap or drift.

Alarm (judgment): inputs are monitoring data and judgment rules (thresholds, trends, composite conditions); outputs are graded alarms (reminder/warning/alarm) with alarm context (which point, which period, which trend). The key is "grading by severity": not pushing every anomaly to the duty operator, but converging by risk into a processable alarm stream.

Actuation (execution): inputs are alarm signals and actuation strategies (local relays, tripping, load shedding, backup-circuit switching); outputs are automatic actions with action receipts. The key is "controllable and non-malicious": millisecond-level local handling, plus anti-maloperation protection and a manual override channel.

Prediction (prevention): inputs are historical monitoring data and equipment characteristics (load rate, temperature-rise patterns, aging trends); outputs are trend forecasts, remaining-life assessments, and maintenance recommendations. The key is "foreseeable and executable": predictions must land in maintenance plans, not stay on curves.

The four stages are progressive and feed back: monitoring supports alarms, alarms trigger actuation, historical data supports prediction, and prediction in turn guides monitoring layout (higher-risk circuits get more points).

3. The Carrier: End-Edge-Cloud Architecture

Landing the four stages requires a three-tier division of labor — the skeleton of the closed-loop design:

End (sensing and execution): sensors and actuators — smart meters, controllers, smart breakers, temperature/humidity probes. The end is responsible for "acquiring" and "acting": collecting raw electrical quantities and executing local opening, load shedding, and locking actions. The end's capability sets the loop's floor: if the end cannot measure, the upper layers are blind; if the end cannot act, actuation has no grip.

Edge (edge computing): the edge gateway handles millisecond-level real-time processing — local data cleansing, local judgment, local actuation. Why must actuation happen at the edge? Because the network and cloud introduce latency and jitter; the handling window for fire-grade hazards (arcing, overcurrent, residual-current spikes) is milliseconds to seconds — waiting for data to reach the cloud and commands to return is too late. The edge holds preconfigured actuation strategies (local relays, breaker tripping, load-shedding commands) and can execute independently even when disconnected — this is the core of the "local actuation safety boundary": actuation strategies reside locally and do not depend on the cloud.

Cloud (platform and models): the cloud handles trend-level analysis — aggregation across devices and periods, trend prediction, remaining-life assessment, alarm convergence, and statistical analysis, outputting maintenance plans and management reports. The cloud does not need millisecond response, but it needs complete, continuous historical data, so the quality and completeness of data the edge uploads directly determine prediction accuracy.

One sentence for the end-edge-cloud division: the end acquires and acts, the edge judges fast, the cloud predicts. This division decides what must be done on-site versus what can go to the cloud, and is why "millisecond actuation" and "trend prediction" can coexist.

In data-flow terms, end-edge-cloud is a "local-processing-first" pipeline: end-side measurement data first passes through the edge gateway for cleansing and local judgment; conditions meeting actuation criteria execute immediately (without traversing the network); meanwhile the edge uploads governed data to the cloud as needed — high-frequency raw values uploaded periodically for modeling, event data (alarms, actions, limit-breach periods) uploaded in real time for audit and reporting. This both guarantees millisecond handling and gives the cloud a complete, clean data foundation for prediction. Note that edge and cloud should support store-and-forward: when the network is interrupted, the edge caches locally and backfills after recovery, avoiding cloud data gaps and distorted predictions from brief outages.

4. Monitoring: Visibility Depends on Points and Data Quality

Monitoring-stage failures usually are not "no meters installed" but "wrong points and dirty data":

  • Where to place points: by circuit and equipment risk — incoming main breakers, heavy-load circuits, temperature-sensitive equipment (switchgear contacts, cable joints), residual-current-sensitive circuits (humid environments, aging lines) first. More points are not always better; "full coverage of critical circuits with reasonable redundancy" is the goal;
  • How to guarantee data quality: continuous (no gaps), accurate (meeting precision), synchronized (multi-point time alignment). Gaps cause missed alarms and distorted predictions; drift causes false threshold alarms;
  • What to acquire: electrical quantities (current, voltage, power, harmonics, residual current) plus non-electrical quantities (temperature, humidity, partial discharge) — the combination covers the four main hazard classes: overcurrent, overheating, arcing, and insulation degradation.

In the FEXLINK ecosystem, the monitoring stage is carried by FSA/FSB/FSE controllers and ZSA/ESA smart meters: controllers acquire electrical quantities close to the circuit, smart meters provide metering and power-quality data, both aggregated and uploaded through the ESX edge gateway. The monitoring acceptance criteria are simple and direct: circuit point coverage, data completeness, and accuracy — three quantifiable indicators.

5. Alarm: Grading by Severity, Converging into a Processable Stream

The most common alarm-stage mistake is "report everything": thresholds too loose flood true alarms with false ones; too tight, real hazards are missed. Grading and convergence are the two key actions:

  • Grading: divide alarms into three levels by risk and handling deadline — reminder (minor limits, trend deviation) goes to logs; warning (near threshold, local overheating) pushes to the operations shift; alarm (overcurrent, arcing, residual-current spikes) triggers actuation and immediate notification. Grading gives every alarm a clear response deadline and handling path;
  • Convergence: merge alarms of the same type, source, and device into one "alarm event" with context (which device, which point, duration, current value/trend). Convergence prevents "one fault, dozens of pushes," letting duty operators face "events" rather than "message floods."

Judgment rules can be in three tiers: single threshold (simple limit), composite conditions (e.g., "temperature over limit + current rising" both true before alarming), and trend judgment (e.g., sustained N-minute rise reaching a rate threshold). The closer rules are to fault mechanisms, the more accurate alarms — this is the value of codifying field experience into rules. Alarm acceptance criteria: both miss rate and false-alarm rate must be controlled, not just "how many alarms there are."

6. Actuation: Controllability Depends on Milliseconds and Safety Boundaries

Actuation turns "alarms" into "actions" — the final step from "visible" to "controllable." Actuation actions fall into three tiers by risk:

  • Notification level (no action): warning-level events; actuation is only sound/light prompting and duty notification;
  • Handling level (automatic action): alarm-level events trigger local relays, load-shedding commands, backup-circuit switching — e.g., when a circuit's current exceeds its limit, the edge automatically reduces that circuit's load or switches to a backup circuit, isolating the fault at its source;
  • Tripping level (power cut): fire-grade hazards (arcing, residual-current spikes, insulation breakdown) trigger breaker tripping, directly opening the faulty circuit — here "cutting power" is safer than "keeping it running."

Three hard rules define the local actuation safety boundary:

  1. Strategies reside locally: actuation strategies are configured at the edge and execute even offline — the tripping decision chain must never sit in the cloud;
  2. Anti-maloperation protection: actuation must carry anti-maloperation mechanisms (confirmation windows, condition recheck, manual veto), so automatic actions do not become "a new source of maloperation";
  3. Actions are traceable: every actuation leaves an audit trail (time, trigger condition, result, manual intervention), reviewable afterward — the foundation for operations management and audits.

In the FEXLINK ecosystem, the actuation stage is carried by FECB2SP/SLP smart breakers (on-site tripping) and the ESX edge gateway (strategy residency and command dispatch). Actuation acceptance criteria: response time (milliseconds), action success rate, and maloperation rate.

7. Prediction: Seeing Far, Landing in Maintenance Plans

Prediction moves the loop from "firefighting" to "fire prevention." Prediction does two things:

  • Trend prediction: based on historical monitoring data, predict where equipment state is heading — e.g., a circuit's load rate keeps rising and temperature-rise rate exceeds normal; predict "reaching the warning value in X days at the current trend," enabling load adjustment or a maintenance window in advance;
  • Remaining life and degradation assessment: combining load history, temperature-rise history, and limit-breach counts to assess aging and output a "recommended maintenance window" — turning "repair after failure" into "repair before failure."

Two conditions are necessary for prediction to land: data accumulation (months of continuous data, or prediction has no statistical basis) and feature engineering (prediction is not extrapolating the historical curve but modeling with features such as load, temperature, and running hours). In the FEXLINK ecosystem, prediction is carried by the Tianyuan prediction engine (trends and remaining life), working with the Qianzhi engine's identification alarms to form an "identify → predict → recommend" prevention chain.

Prediction lands as maintenance plan recommendations: the system outputs "recommend scheduling maintenance for device X within 30 days — basis: temperature-rise rate exceeded the baseline by 20% for 4 consecutive weeks, predicted remaining operating margin insufficient" — not a curve for operators to interpret themselves. Prediction acceptance criteria: prediction accuracy (share of warnings actually verified) and maintenance recommendation adoption rate.

Landing predictive maintenance also requires answering "where do plans come from and how are they scheduled": the prediction engine outputs not single recommendations but a prioritized maintenance recommendation list — sorted by equipment risk and remaining margin, annotated with recommended windows, estimated effort, and risk level. Operations schedules it into monthly plans instead of waiting for failure. This turns prediction from a "data product" into a "management tool": equipment registers, work orders, and spare-part plans all connect to prediction results, forming a "predict → plan → execute → verify effect" loop. The verification link matters most: whether equipment state improved after maintenance and whether predictions were accurate must be written back to the database to keep calibrating the model — prediction is not done at launch; it gets more accurate with use.

8. Case Views: How the Loop Plays Out in Typical Scenarios

The same loop lands differently by scenario. Three anonymized examples show how "monitor–alarm–actuate–predict" adapts:

An industrial park's distribution room (incoming and critical circuits): the incoming main breaker and critical circuits are equipped with controllers and smart breakers; the edge gateway hosts actuation strategies. On a composite alarm of "residual-current spike + temperature over limit," the edge automatically opens the faulty branch within 300 ms and pushes the alarm event; meanwhile the cloud, based on recent temperature-rise trends, flags "this branch cable shows suspected insulation degradation; recommend maintenance within 14 days." Handling changes from "a person runs to the site" to "on-site isolation + planned maintenance."

A factory production line (continuity first): line circuits are sensitive to power cuts, so tripping-level actuation cannot be used directly. The strategy becomes "limit shedding + backup-circuit switching": when a circuit's current exceeds the limit, the edge automatically sheds 20% of load and attempts backup switching while pushing the alarm; the cloud model assesses "at the current load trend, the limit will be exceeded again in 2 hours," recommending staggered production in advance. The actuation boundary here is "supply continuity first, isolation as backstop."

An airport terminal (high-reliability requirement): critical loads (security, emergency lighting, flight information) get dual protection: monitoring covers contact temperature and residual current, actuation is limited to notification and shedding, tripping executes only after manual confirmation; the cloud supports annual maintenance scheduling with remaining-life assessment. The scenario's character is "conservative automatic action, generous prediction investment" — high-reliability scenarios rely more on prevention than fast cutting.

The three cases show one point: the loop skeleton is unified; parameters vary by scenario. Actuation levels (notification/handling/tripping), alarm thresholds, and prediction periods must be configured by load criticality and process requirements, not one strategy for everything.

9. Loop Maturity and Data Requirements

The loop is not built overnight. Assess maturity in four stages and build level by level:

  • L1 passive monitoring: monitoring and simple alarms only, handling by people — the status quo at most enterprises;
  • L2 graded alarms: grading and convergence, rules close to mechanisms, duty response follows procedure;
  • L3 local actuation: millisecond actuation online (notification/handling/tripping), hazards handled on-site;
  • L4 predictive prevention: trend prediction and maintenance recommendations enter operations planning — the loop is closed.

Data requirements run through all four stages: continuous, clean, time-aligned. Monitoring data quality directly decides whether alarms are accurate and predictions work — so data governance is not late-stage work but the first step of loop construction. We recommend advancing on the trio of "point list → data-quality baseline → actuation/prediction strategy library," adding one tier of data and strategy per maturity level rather than piling everything at once.

10. Common Pitfalls and How to Avoid Them

  • Pitfall 1: monitoring without handling. However many alarms, if the handling chain is broken, the system is still a "number display";
  • Pitfall 2: putting actuation decisions in the cloud. Offline means failure, and millisecond handling is impossible — actuation must reside locally at the edge;
  • Pitfall 3: automatic actuation without anti-maloperation. Without confirmation and recheck, the loss from maloperation can exceed the hazard itself;
  • Pitfall 4: prediction divorced from data quality. With gaps and inconsistent conventions, prediction is just "curve extrapolation" — untrustworthy and unexecutable;
  • Pitfall 5: treating "many alarms" as "a good system." Alarms must converge and grade; floods of pushes mean rules are not close to mechanisms;
  • Pitfall 6: one strategy for everything. Different load criticality needs different actuation levels and prediction periods; strategies must be configured per scenario and iterated with operating data.

Scope and Limitations

The "monitor–alarm–actuate–predict" closed-loop design on this page (end-edge-cloud division, millisecond edge actuation, cloud trend prediction, four-stage maturity) is this article's methodology for electrical-digitalization planning reference and does not constitute a project implementation plan. Related product capabilities (FSA/FSB/FSE controllers, ZSA/ESA smart meters, the ESX smart edge-computing gateway, FECB2SP/SLP smart breakers, the Tianyuan prediction engine, the Qianzhi identification engine, the predictive-maintenance solution, and the digital electrical intelligent supervision system) come from the FEXLINK product knowledge base as product-documentation conventions. Statements such as "milliseconds," "X days," and "30-day maintenance recommendation" are methodological illustrations; actual response times and prediction periods depend on site network conditions, equipment characteristics, and data quality. Local actuation involves power-cutting safety actions; specific strategy configuration must be assessed and determined by qualified professionals based on site load criticality and process requirements. Example scenarios (an industrial park, a factory, an airport, a port) are anonymized illustrations and do not refer to any specific customer.