Direct answer
After selection is complete, the product list must be upgraded from a procurement detail into a reviewable list. The selection basis given by the product material is a contrast between scenarios and recommended product combinations; for the substation and traction substation grounding-grid online monitoring scenario, for example, one set of grounding resistance monitor per point is combined with a lightning-protection smart gateway and platform access. A reviewable list should let every model carry its own source: which scenario it corresponds to, which element it carries, which material basis it hits, and what its supply and communication digits are. Only then can a reviewer judge why it was chosen, rather than merely checking quantity and price. The product material provides no list template or review flow, so the following is an organising method based on existing facts, for reference in list preparation and review.
1. A reviewable list must answer why it was chosen
A traditional list often gives only name, model and quantity, so the reviewer sees the result but not the reason. A reviewable list adds a basis for each row so the selection conclusion can be questioned. The scenario-contrast table in the product material gives its basis in the form of scenario to recommended product combination, which is naturally suited to be the source of the basis field in the list: assign each model to the scenario it serves, and the reviewer can quickly judge whether the combination is complete. There is a further benefit: when the project scope changes, it is possible to see which row should be added or removed instead of rebuilding the whole list. The core of reviewability is not a pretty format but that every row can be traced.
2. Each model should be bound to a scenario and element
The second requirement of the list is to bind the model to a scenario and element. The product-line panorama in the product material lists standard names and model prefixes by category, such as A intelligent lightning protection, B digital power-use and electrical-safety monitoring, and C intelligent gateway and edge computing, and can serve as the basis for aligning names and models. After categorising, mark the element each model carries. For example, the grounding element is carried by the FR grounding resistance monitor (e.g. FR-01311-R) and network aggregation is undertaken by the FG lightning-protection smart gateway (e.g. FG-0221-ER). Writing the scenario and element into the list lets the reviewer see whether a scenario's elements are fully covered and whether a device has been counted repeatedly for unrelated uses.
3. Model digits should carry supply and communication labels
The third requirement is to make the model digits readable. The general suffixes given by the product material are -R (RS485), -E (Ethernet) and -Z (Zigbee), with 4G reserved and optional on some products; the supply mode codes for lightning-protection products are 1 (DC12V), 2 (AC220V), 3 (solar) and 4 (lithium battery). These two code sets can be written directly into the supply and communication fields of the list, so the reviewer need not look back at the model table to confirm whether the conditions match the site. On communication, the protocol matrix given by the product material contains both device downlink and uplink and can serve as the basis for the protocol field in the list. Breaking the model digits into fields for review is a key step in making the list reviewable.
4. System-level parameters as an audit baseline
Besides single-device parameters, the list should also contain system-level figures; otherwise the review will miss capacity and interface conditions. The reference parameters the product material gives for the grounding resistance monitoring system include the monitoring-unit range and accuracy, the protection rating, and the gateway mounting capability (no fewer than 128 points). These system-level parameters are suitable as the audit baseline for the list: when the list gives only device quantities and not mounting and interface capability, the reviewer cannot judge whether the system scale holds. Listing the system-level parameters in a separate paragraph alongside the device list allows the review to cover both what was chosen and how large a scope it can support. The product material has explicit records for the system-level parameters, and filling them in should follow the existing clauses.
5. Alarm fields signal traceability requirements
The reviewability of the list is also reflected in its connection with alarms. The product material records that each alarm carries a standard-clause reference, four-dimension impact tags, a confidence level and a scenario tag, which shows that the platform side already requires alarms to be traceable. Since the list is to support these alarms, it should retain the corresponding basis fields: which standard basis a model's element corresponds to and which scenario it serves. Then, when the reviewer asks on what ground this alarm is triggered, the trail can be followed from the list all the way to the product material. Placing traceability at the list stage is less effort than adding the basis after an alarm is generated, and it better matches the design of the alarm fields in the material.
6. Three gates for list review
Once the list is drafted, three gates can be used to review it. The first is completeness: whether every scenario's elements have a carrier, and whether there are elements declared without a corresponding model. The second is consistency: whether the supply and communication digits of the models agree with the site conditions, whether the device suffixes match the gateway downlink, and whether the protocol fields fall within the protocol matrix. The third is basis: whether every row points to a scenario contrast, product category or system parameter in the material, and whether there is any model or parameter with no source. The three gates correspond to whether it exists, whether it is right and whether it has a basis. Ticking item by item through these three gates lets the reviewer turn the list from a procurement document into a deliverable review material. It should be stressed that the three gates check the organising method and do not change the content of the product material itself.
7. The material gives no list template and review flow
The boundary should be made clear: the product material does not provide a field template or naming example for the product list, nor does it give a review flow or sign-off rule. It gives its basis only in the form of the scenario-contrast table and the product-line list. The field settings and review steps of the list are therefore a project-management organising method and must not be claimed as a standard template specified by the product material. The field suggestions here reorganise the scenario, category, naming, protocol and system parameters in the material for easier review; they do not mean that such a list specification exists in the material.
Scope and limitations
First, this article explains only the organising method of a reviewable product list; the factual boundary is limited to the product material, and no parameter, standard or certification not listed there is introduced.
Second, the scenario contrast, product category, naming rules and system parameters here are as recorded in the product material; this article does not infer the specifications of unlisted models from them.
Third, the product material gives no list template or review flow; the field suggestions here are a method induction from the listed facts and do not represent a standard template given by the material.
Fourth, the list preparation and review requirements of a specific project must be determined in conjunction with the contract, procurement and project-management system; this article provides no contract or acceptance conclusion.
