Direct answer

On how the identification and scenario location of lightning-protection monitoring points are established, the product knowledge base gives two languages: the scenario-location tree of the Wanxiang engine, eighteen levels in total, going down level by level from the park level to the wiring-terminal level and the contact-point level; and the five classes of electrical topology location type of location awareness - point of common coupling, main distribution panel, distribution panel, feeder line and load terminal. The material states that an alert can be located precisely to "workshop No. 3, power cabinet, fifth outgoing terminal", with a scenario-location precision reaching the seventeenth and eighteenth levels; the platform layer and application layer handle alert presentation and location. The material gives no coding or naming rule for point identification, only the scenario-location tree levels and the location types as the location language. This article explains by what dimensions point identification and scenario semantics are established, not how the identification is coded.

1. What point identification must answer

Once monitoring points multiply, whether an alert can land on a specific location depends on whether every point has both an identity and an attribution. Identity answers "which point it is", attribution answers "where it sits in the system". The scenario-location tree of the product knowledge base solves attribution, and the location types solve electrical semantics; together they form the location language usable for point identification.

Keeping the two apart matters: with a number but no attribution, an alert is only a string of codes; with attribution but no number, several points of the same level and class cannot be distinguished. The material gives exactly this combination of two dimensions, not a ready-made numbering scheme.

2. The hierarchical skeleton of the eighteen-level scenario-location tree

The product knowledge base lists the scenario-location tree as eighteen levels, starting from the park level and containing levels such as building, floor and distribution area, down to the seventeenth-level wiring-terminal level and the eighteenth-level contact-point level. This tree is the hierarchical skeleton for establishing point identification and scenario location.

The meaning of the levels is subdividability. Pushing down to wiring terminals and contact points means point identification can describe a location specifically enough without stopping at the coarseness of "some building". The material gives the level capability, not the specific naming rule of each level.

3. The five location classes as scenario semantics

Beyond the levels, location awareness gives five classes of electrical topology location type: point of common coupling, main distribution panel, distribution panel, feeder line and load terminal, and maintains an independent threshold and risk model for each. This provides a point with electrical semantics, showing which stage of supply and distribution it sits in.

The levels answer "which spatial level", and the location classes answer "which stage of supply and distribution". Only where the two cross does a point have complete semantics: it can be located by spatial level and explained by electrical role. The material supports this cross-location but gives no mapping table between the two.

4. The example of alert location to an outgoing terminal

The product knowledge base gives a concrete example: an alert can be located precisely to "workshop No. 3, power cabinet, fifth outgoing terminal", with a scenario-location precision of the seventeenth and eighteenth levels. This example shows the fineness of point identification can support alert presentation down to the circuit level.

The value of the example is to land the abstract levels on a readable location description: the workshop is the spatial level, the power cabinet is the distribution equipment, the fifth is the circuit, and the outgoing terminal is the terminal level. Only by combining these fragments can a maintenance person find the site location from them. The material gives this capability example, not the construction rule of the identification string.

5. Point identification at the platform and application layers

The product knowledge base summarises the monitoring system as a four-layer architecture, in which the platform layer is the FEXCloud IoT cloud platform and the application layer includes Web and App visualisation, alert management, analysis reports and mobile inspection. Point identification is ultimately used at the platform and application layers for alert presentation and location.

This shows the identification is not an accessory field on the acquisition side but a location basis usable on the application side. Only when data goes up carrying the point identification can the platform land an alert on a specific location; the application layer then presents those locations as visualisation or work orders. The material gives the layer division, not a field-level specification.

6. Scenario-tree management and the location-awareness engine

Under the Wanxiang engine entry, the product knowledge base lists nine dedicated analysis engines, including the scenario-tree management engine and the location-awareness engine, and gives quantitative values: a scenario-location precision of the seventeenth and eighteenth levels and an alert-compression ratio of eighty percent.

Placing the two engines beside the quantitative indicators shows the position of point identification in the system: scenario-tree management maintains hierarchical attribution, and location awareness interprets data by location; together they support location and alert compression. The material gives the engine names and indicators, not the algorithm implementation.

7. Location correction and assessment

In the special sub-model entry of the Qianzhi engine, the product knowledge base lists the temperature sub-model among the basic vital signs and marks that it uses location-awareness correction. This shows the data of the same measuring point participates in assessment together with location information, and point identification thus becomes a precondition of location correction.

Without reliable point identification, location correction cannot be applied: the system cannot tell which class of location a temperature reading belongs to and cannot apply the corresponding threshold. The material supports the relation "identification is a precondition of location correction" but gives no correction formula.

8. Material boundary: no coding rule

The product knowledge base gives no coding or naming rule for point identification, such as how an equipment number or point number is constructed. It provides only the levels of the scenario-location tree and the location types as the location language. This article can therefore explain by what dimensions to establish identification, not the specific format of the identification.

Stating this boundary avoids using level names or location types directly as a coding specification. In practice, the coding format still has to be agreed separately and must correspond to the levels of the scenario tree.

Scope and limitations

First, this article restates only what the product knowledge base lists. The eighteen-level scenario-location tree, the five location classes, the alert-location example, the four-layer architecture, the dedicated engines and the location correction are all cited as recorded.

Second, the material gives no coding or naming rule for point identification; this article infers no specific coding scheme and gives no equipment-number or point-number format.

Third, the scenario-location precision and alert-compression ratio are cited as listed; this article promises no location or compression effect for any project.

Fourth, the specific point-identification system must be agreed separately against the site device list and maintenance requirements; this article provides no coding or configuration scheme.