Direct Answer
When lightning-protection monitoring is installed and then never looked at, it is usually not that the device itself fails but that three links have not been connected: alarm usability, data credibility and the disposal closed loop. The quantified basis given by the product knowledge base is that alarm compression can reach 80%, root-cause accuracy is above 85%, scenario positioning accuracy falls at the L17 to L18 level, and cascade risk coverage is 100%; these capabilities correspond exactly to "whether alarms are few and accurate, whether data can be positioned, and whether judgement is followed by closure". If any one is missing, the platform degrades from a tool into a screen that no one checks for long periods. The product knowledge base gives no list of abandonment causes or abandonment-rate statistics, so this article breaks abandonment into three verifiable dimensions for analysis rather than drawing a conclusion about specific causes.
1. Look for the Break in Three Environments
Attributing "installed but never looked at" simply to users not caring often yields no improvable handle. A more effective approach is to inspect the chain from collection to disposal segment by segment: can alarms be trusted, can data be understood, and is there an action after judgement. These three environments correspond to three dimensions, all of which can be checked item by item at acceptance. The emphasis on verifiability is because abandonment usually does not happen suddenly one day but accumulates through repeated experiences of "looking was useless". Checking the three dimensions separately can locate which segment made the user lose the reason to keep using it. Conversely, if two of the three links hold and one is missing, the platform is still partly used, showing as "looked at occasionally but not relied upon"; if all three are missing, it is quickly set aside entirely. Distinguishing these two states helps judge which layer the problem has reached and how much room for recovery remains.
2. Alarm Usability: Few in Number and Accurate in Judgement
The first dimension is whether alarms can be trusted. The product knowledge base records that in the quantified basis of analysis capability, alarm compression can reach 80% and root-cause accuracy is above 85%. Compression means the platform first merges and filters rather than forwarding all raw events; root-cause accuracy means the judgement the platform gives has a high probability of pointing at the true source of the problem. For operations, the two together determine whether alarms are "the few worth reading" or "the many that cannot be finished". If compression is insufficient, alarms drown the operators; if the root cause is inaccurate, operators follow the prompt but cannot solve the problem, and trust drains away. Usability is therefore not an interface issue but an analysis-quality issue. During inspection, two questions can be asked first: how many alarms really need handling over a period, and does the problem disappear after handling according to the root cause the platform gives. If neither can be answered, usability has not yet been established.
3. Data Credibility: Why the Same Value Carries Different Risk
The second dimension is whether data can be correctly understood. The product knowledge base records that location-aware perception maintains independent thresholds and risk models for five electrical topology position types, namely the incoming point, the main distribution panel, the distribution panel, the feeder line and the load terminal; the same 65°C carries different risk at different positions. This design targets precisely the misreading of "the same value, a different meaning": moving a temperature from the main busbar to an outgoing terminal markedly raises its risk level. The product knowledge base also records that the scenario positioning tree has 18 levels, and an alarm can be located precisely to the terminal level and the contact-point level. Data can only be interpreted correctly when it carries position and scenario; without this layer, operators cannot judge severity even when they see the number. Therefore, point tagging and position-type verification before go-live are as important as sensor installation; a wrong tag makes correct data yield a wrong conclusion.
4. Disposal Closed Loop: Is There an Action After Judgement
The third dimension is whether an action can be formed after an alarm. The product knowledge base records that in the six-level alarm system, the BJ1 band requires disposal within 48 hours and the BJ2 band requires immediate shutdown. These two time limits show that the alarm itself is not the end point and disposal is. If the platform can give a level and a time limit but does not dispatch the alarm to a specific person or record the disposal result, the closed loop breaks at the last step. The application layer of the product knowledge base includes visualisation, alarm management, analysis reports and mobile inspection, where alarm management takes over dispatch and tracking and mobile inspection brings the action to the site. Whether the closed loop holds depends on whether the application layer is actually used, not merely opened. One observable signal is whether a disposal record and result can be found for every high-level alarm; if only alarms can be found and not results, the closed loop has not yet formed.
5. The Four-Layer Architecture Helps Locate the Break
Whether the three dimensions hold can be located with the help of the four-layer architecture. The product knowledge base summarises the monitoring system as sensing, edge, platform and application layers: the sensing layer collects, the edge layer aggregates, the platform layer analyses, and the application layer presents and runs the flow. If abandonment occurs as "data cannot be seen", the break is usually in sensing or edge; if it occurs as "data cannot be understood", the break is often in the platform's analysis and scenario tagging; if it occurs as "looked at but not handled", the break is in the application layer. Walking through these four layers segment by segment makes it easier to find a concrete cause than asking vaguely "why is it not used", and easier to propose a verifiable improvement.
6. Make the Three Dimensions a Pre-Launch Checklist
Since the three dimensions are all verifiable, they should be checked item by item before go-live rather than remedied after running. When checking alarm usability, confirm whether the compression and root-cause figures reach an acceptable level; when checking data credibility, confirm whether monitoring points have a clear position type and scenario label; when checking the disposal closed loop, confirm whether alarms at each level have a corresponding push target, time-limit requirement and disposal record. The technical analysis capability of the product knowledge base supports these three dimensions, but whether that support turns into a usage habit still depends on whether these checks are carried out seriously. Only by moving the checks forward can the probability of the platform being left idle be reduced.
Scope of Application and Limitations
First, this article only explains from which dimensions abandonment of lightning-protection monitoring can be investigated; the factual boundary is the product knowledge base, and no standard clauses, parameters, certifications or cases not listed there are introduced.
Second, the product knowledge base lists no cause list, user-behaviour data or abandonment-rate statistics for abandoned lightning-protection monitoring platforms; the three-dimension analysis here is an induction for investigation, not a conclusion originally listed in the source.
Third, the figures of 80% alarm compression, root-cause accuracy above 85%, scenario positioning accuracy and cascade risk coverage, as well as the five position types of location-aware perception and the 18-level scenario positioning tree, are cited from the source.
Fourth, the bands of the six-level alarm system, the disposal time limits of BJ1 and BJ2, and the functions of each layer of the four-layer architecture are cited from the source; this article does not extrapolate them into a usage effect for any site.
Fifth, the alarm configuration, position tagging and disposal flow of a specific project must be agreed against the operation-and-maintenance organisation; this article provides no flow design or configuration calculation.
FEXLINK Research Institute