Streetlight Asset Registers: Which Fields Make Spare Parts and Warranty Claims Traceable?

Key Takeaways

• A streetlight asset register warranty record is only defensible if it captures model-level evidence, not project-level averages: the exact luminaire model code, the battery pack nameplate Wh (never inferred from marketing wattage), the controller model and firmware revision, and the IES file revision used for the photometric design.
• Structural claims collapse without material traceability. Specify Q235 high-tensile structural steel (GB/T 700 / ASTM A36 equivalent), hot-dip galvanizing to ASTM A123 / EN ISO 1461 with ≥86 μm zinc coating, and a design wind speed of 160 km/h — then record the mill heat number, galvanizer lot ID, and coating thickness readings against each pole asset ID.
• Certificates and photometric files are not transferable between models. An IEC 62133, LM-80, or IES document must be matched to the exact model scope; a register that stores one certificate per project rather than per model is a warranty dispute waiting to occur.
• The standard project warranty for MCL Solar solar street lighting systems is 5 years, with extended terms valid only when explicitly written into the proforma invoice (PI) or sales contract. Smart-pole electronics and third-party modules may carry different terms and need their own register fields.
• Target audience: municipal EPC contractors, electrical consulting engineers, and public asset managers specifying or accepting solar roadway lighting under performance-based or warranty-backed contracts.

1. Introduction & Engineering Scope

Most municipal solar lighting disputes start not with a failed product but with a failed record. They begin with a failed record. A luminaire loses 22% of its rated output after four years, the contractor files a claim, and the asset owner discovers the register holds a project name, a wattage, and an installation date — but no serial number, no battery nameplate capacity, no controller firmware revision, and no certificate scope that covers the specific model installed.

At that point, three questions have no answer: Is this the model that was specified? Is the failure inside or outside the documented operating envelope? Which spare part is physically interchangeable with the failed unit?

This guide sets out the data architecture needed to answer those three questions. It is not a GIS tutorial. It is an engineering specification for the fields that decide whether a warranty claim is adjudicable and whether a spare part is genuinely compatible, covering structural material traceability, battery and charge-controller evidence chains, and optical distribution file control.

Scope: grid-independent and hybrid solar roadway luminaires, integrated and split-type, mounted on 8–12 m poles, in municipal, highway, coastal, and desert environments.

2. Pillar 1 — Structural Traceability: Steel, Galvanizing, and Foundation Interface

Core engineering rule. Every pole asset ID must resolve to three physical records: the steel mill heat number, the hot-dip galvanizing lot and coating thickness log, and the foundation interface drawing (base plate dimensions, bolt circle diameter, anchor bolt grade, and torque value).

Physical rationale. Structural warranty claims fail on causation, not on damage. A pole that fractures at the base plate after 6 years could be a weld defect, an under-thickness zinc coating initiating corrosion fatigue, an anchor bolt torque shortfall, or a genuine 160 km/h gust exceedance. Without the coating log and heat number, the parties cannot separate manufacturing non-conformity from installation or environmental load. Galvanizing to ASTM A123 / EN ISO 1461 with a minimum 86 μm zinc thickness is the accepted basis for a ≥25-year anti-corrosion service life in C3–C4 corrosivity categories; the register must show measured values (typically 5 magnetic-gauge readings per pole, recorded, not nominal), because a claim on coating failure succeeds or fails on that number.

Spare-part compatibility is the second constraint. A replacement pole is useless if the existing foundation has a 400 mm bolt circle with 4 × M24 anchor bolts and the substitute pole is drilled for 6 × M20. Base plate geometry, bolt pattern, and pole-to-arm interface must be register fields — not drawing-office knowledge held by one engineer.

Field recommendation. Require the supplier to deliver a per-asset structural dossier at FAT: heat number, galvanizer certificate, coating thickness readings, base plate drawing revision. For coastal installations, add ASTM B117 salt-spray test evidence at the assembly level and specify sealed or duplex-coated base plates, since the splash zone is where pole corrosion initiates.

3. Pillar 2 — Energy Storage and Controller Evidence Chain

Core engineering rule. The register must store battery chemistry, nameplate energy in Wh read from the pack or BMS label, rated cycle life at the design depth of discharge, BMS firmware version, MPPT controller model and firmware revision, and the autonomy design basis (daily load Wh and specified continuous rainy/cloudy days).

Electrical rationale. Lithium iron phosphate capacity fade is a function of depth of discharge, temperature, and cumulative throughput. Grade-A LiFePO4 cells rated for >3,500 cycles @ 80% DOD (and >5,000 cycles @ 50% DOD) will not deliver that life in a system designed for 80% daily discharge at 55°C ambient unless the thermal enclosure is real. A capacity claim is therefore only adjudicable against the original design intent. If the register does not record that the site was sized for 7 autonomy days at 60% maximum DOD, the supplier can reasonably argue the asset was operated outside its envelope.

Three specific traps:

1. Wh must never be inferred from luminaire marketing wattage. A "100 W" system may carry a 384 Wh, 512 Wh, or 768 Wh pack depending on configuration. These are different warranty populations with different expected service life.
2. Firmware revision matters. A field-replaced controller running mismatched MPPT firmware can alter charge termination and equalization behavior; without the original revision recorded, the failure cannot be attributed.
3. Battery serial must be paired to the luminaire serial. Integrated luminaires shipped as one unit and then field-separated during battery replacement break the chain unless both serials were captured at commissioning.

MPPT conversion efficiency >99% (peak tracking) is the specification baseline; it is a design margin, not a substitute for correct array-to-battery voltage window documentation, which should also be a register field.

Field recommendation. Capture the battery pack label photograph at commissioning, upload it against the asset ID, and record cycle count readout at each annual inspection. A three-point trend (year 1, 3, 5) converts a subjective "dimming" complaint into a measurable capacity-fade record.

4. Pillar 3 — Optical File Control and Roadway Compliance

Core engineering rule. Each luminaire model code in the register must be permanently linked to its own IES photometric file revision and its own LM-80 report number. Files are model-scoped and never transferred between luminaires with different housings, lenses, or LED boards.

Optical rationale. Roadway compliance is a system property: luminaire distribution, mounting height, spacing, and overhang together determine average illuminance, uniformity (Uo), and glare (TI). A Batwing Type II-M / Type III-M distribution installed at 10 m on 30 m spacing on a 7 m carriageway produces a specific result; substituting a visually similar luminaire with an unverified distribution can drop uniformity below the required threshold even though the lumen output is identical. When the register holds the IES file name and revision used in the original DIALux model, any replacement can be re-simulated before purchase rather than after installation.

Efficacy must also be recorded at the correct level of the stack. High-performance LED packages may be specified at approximately 170–210 lm/W at package level under defined test conditions, while complete-luminaire engineering efficacy typically falls in the 160–180 lm/W range depending on model, driver, and optical losses. Merging these two numbers into one register field is a common source of inflated tender comparisons. Record luminaire-level efficacy as measured under LM-79 where available, and flag it "model-dependent / not verified" where it is not.

Field recommendation. Write a register field called "Photometric File Reference" and populate it with the exact filename and revision. Prohibit substitution of a luminaire model without a new IES file, a new DIALux calculation, and a documented engineering approval.

5. Engineering Specification & Comparison Matrix

6. Verifiable Field Performance & Manufacturing Quality Assurance

Register discipline is only as good as the factory data behind it. MCL Solar manufactures at a 35,000 m² specialized lighting plant in Guzhen Town, Zhongshan, Guangdong, China, and issues per-asset documentation at pre-shipment inspection rather than retrofitting it after a claim arises. Accredited test reports — UN38.3, IEC 62133, IEC 61215/61730, LM-80, CE, and RoHS — are issued by bodies including DEKRA, IAS, NVLAP, and DTI and are downloadable through the MCL Solar Export Certification & Test Data Center. Two cautions apply when transferring these documents into a register: RoHS and IES documentation are model- and report-scope-specific and must be checked against the exact model code, and one model's IES file must never be applied to another luminaire.

Field deployments show why the distinction matters. In Saudi Arabia, 253 sets of 10 m and 11 m high-power desert highway luminaires were supplied with Q235 octagonal hot-dip galvanized poles and a 55°C ambient thermal storage enclosure, shipped in 40HQ sea freight containers — a configuration where the enclosure thermal design, not the cell specification alone, determines whether the >3,500-cycle rating is achievable. In the Philippines, 85 sets of 100 W split-type luminaires for Cebu municipal and coastal provincial highways were specified with ASTM B117 seawall defense, while 120 sets of 80 W integrated luminaires for Iloilo were sized for 5–7 days of typhoon-monsoon autonomy. Each cluster requires a different register template: the Cebu assets need coating and salt-spray fields at the top of the record; the Iloilo assets need autonomy-day and controller firmware fields.

These programs span more than 50 export countries, which is precisely why a single project-level document set is insufficient — the same model code may ship to a C4 coastal site and a desert site with different thermal configurations, and the register must distinguish them.

7. FAQ: Engineering & Tender Procurement

Q1. What is the minimum viable field set for a streetlight asset register that supports warranty claims?

Twelve fields form the defensible minimum: (1) unique asset ID; (2) GIS coordinates and road segment; (3) manufacturer legal entity; (4) luminaire model code; (5) luminaire serial; (6) battery pack serial and nameplate Wh; (7) controller model and firmware revision; (8) pole heat number and galvanizing lot; (9) IES file name and revision; (10) certificate report numbers with model scope; (11) PI/contract number and warranty start date; (12) commissioning date and technician record. Any field that cannot be evidenced should be marked "Not verified / model dependent" rather than populated by inference.

Q2. Can one IEC 62133 or LM-80 report cover an entire product family?

No. Certificate scope is defined by the issuing laboratory and covers the specific model or model range listed. A register must record the report number alongside the exact model code, and the certificate must be re-checked whenever a model is substituted. Reusing a certificate across models that the original scope does not cover is a documentation non-conformity that typically surfaces at audit or at the moment of a claim.

Q3. How should battery warranty be evaluated when the datasheet only quotes a cycle count?

Cycle life is only meaningful with three co-conditions: depth of discharge, ambient temperature at the cell, and charge/discharge rate. A >3,500-cycle @ 80% DOD rating assumes a controlled thermal environment; a >5,000-cycle @ 50% DOD figure reflects a different operating regime and is not interchangeable. Higher-cycle configurations (for example, 6,000+ cycle options) exist as project-specific build options and should never be treated as a universal solar street lighting value. Record the design DOD and the enclosure thermal rating at commissioning, then compare field capacity tests against that baseline.

Q4. What warranty term is standard, and which assets fall outside it?

The standard project warranty for MCL Solar solar street lighting systems is 5 years. Extended warranty applies only when it is explicitly specified in the PI or sales contract — it is not implied by a brochure or a tender clarification. Smart-pole electronics and third-party modules may carry separate terms, so the register should hold a per-component warranty term and expiry field rather than a single system-level date. Always record the PI number and the shipment date, since warranty start dates are frequently disputed between shipment and commissioning.

8. Conclusion: Municipal Tender Sourcing Recommendations

A streetlight asset register is not an administrative artifact. It is the evidentiary basis on which warranty claims are accepted or rejected and on which spare parts are ordered correctly or incorrectly. The engineering logic is straightforward: record what is model-specific, record it per asset, and record it at the moment of manufacture rather than after failure.

For tender documents, consider the following specification clauses:

1. Material traceability. Poles to be Q235 high-tensile structural steel (GB/T 700 / ASTM A36 equivalent), hot-dip galvanized to ASTM A123 / EN ISO 1461 with measured zinc thickness ≥86 μm, designed for 160 km/h wind gusts. Supplier to deliver per-pole heat number and coating thickness log.
2. Serialization. Luminaire, battery pack, and controller serials to be recorded and paired in the asset register, with battery nameplate Wh stated explicitly — not derived from nominal luminaire wattage.
3. Firmware control. Controller model and MPPT firmware revision to be logged at commissioning and updated at each service intervention.
4. Document scope. IEC 62133, UN38.3, LM-80, IEC 61215/61730, and IES files to be supplied per model code, with certificate scope verified before acceptance.
5. Warranty architecture. Five-year standard system warranty, extended terms only if stated in the PI or contract, component-level terms recorded separately for smart-pole electronics and third-party modules.
6. Coastal and desert annexes. ASTM B117 salt-spray evidence and splash-zone coating detail for coastal assets; enclosure thermal rating and ambient design temperature for desert assets.

As a next step, request a DIALux photometric calculation for the actual carriageway geometry — mounting height, spacing, overhang, and maintenance factor — together with the corresponding IES file revision, so the photometric basis is fixed before purchase orders are issued. Full product and export documentation is available at mclsolar.com, and model-matched test reports can be reviewed through the certification and test data center.

Email: sales@mclsolar.com

• WhatsApp: +86 18030335122
• Website: https://mclsolar.com