Smart Pole Platform Acceptance: Test Offline Operation, Alarm Recovery and Data Ownership

Key Takeaways

• Offline operation is a hardware-and-firmware property, not a dashboard feature. Acceptance should physically sever the WAN link or remove the SIM, then require the local controller to hold the full dimming schedule and buffer interval data for at least 72 hours — extended to 7 days where the tender specifies 5–7 day rainy/cloudy autonomy.
• Alarm recovery must be tested as a closed loop (detection → notification → acknowledgement → remediation → automatic clear). Specify a debounce of ≥3 consecutive samples or ≥5 minutes before an alarm is raised, plus a defined clear condition, to suppress cloud-transit and transient-load alarm storms.
• Data ownership is both a contractual and a technical deliverable: documented REST/MQTT API, CSV/JSON bulk export, retention across the asset design life, and complete data return within 30 days of contract termination without per-record fees.
• A platform is only as trustworthy as its telemetry substrate. Q235 structural steel poles hot-dip galvanized to ASTM A123 / EN ISO 1461 (zinc ≥86 μm), Grade-A LiFePO4 cells rated >3,500 cycles at 80% DOD, and MPPT conversion efficiency >99% are the physical references against which every alarm threshold must be calibrated.
• Intended audience: municipal asset owners, EPC contractors, electrical engineers, and procurement directors specifying or commissioning networked solar lighting and smart pole infrastructure.

1. Introduction & Engineering Scope

Smart pole tenders have shifted from "supply and install luminaires" to "supply, integrate, and hand over a managed asset." A single pole may now carry LED roadway lighting, CCTV, environmental sensors, WiFi, public broadcasting, emergency call, LED information display, and EV charging — each module available as a project option and frequently sourced from different OEMs. The control platform is expected to unify them.

In practice, acceptance testing often stops at the demonstration stage: the integrator logs into a cloud dashboard over a stable office connection, toggles a dimming profile, opens an alarm panel, and the project is signed off. Three failure modes then appear 12–24 months later:

1. Backhaul outages leave the corridor uncontrolled. The local controller holds no schedule, and the site reverts to a fixed output that exhausts the battery during consecutive overcast days.
2. Alarms never clear, or never fire. Thresholds are single-sample triggers, generating hundreds of notifications during normal cloud transit; genuine battery-cell divergence is buried in the noise.
3. Data is trapped. Historical telemetry exists only inside a vendor portal, export is a paid professional service, and the authority cannot substantiate a warranty claim or benchmark asset degradation.

This guide defines an acceptance protocol across three verifiable domains — offline operation, alarm recovery, and data ownership — and anchors each domain to measurable hardware references so that acceptance is repeatable, auditable, and independent of the vendor's own demonstration. MCL Solar's engineering and integration experience across desert and coastal municipal projects informs the test criteria throughout; where module data is involved, the original equipment manufacturer of that module should be identified in the handover documentation.

2. Core Technical Pillar 1 — Offline Operation: Testing the Fallback Control Layer

Core Engineering Rule

The platform shall be accepted only after a physically isolated WAN test: disconnect the uplink, disable the SIM, or apply a firewall drop at the site router. The local controller must then (a) continue executing the stored seasonal dimming profile, (b) retain real-time clock accuracy within a defined drift budget (≤1 s/day is a practical benchmark), (c) buffer interval records — 15-minute resolution is typical — for a minimum of 72 hours, and (d) resynchronise after reconnection without duplicating or conflicting with queued commands.

Physical and Electrical Rationale

Offline autonomy is governed by the energy chain, not the software layer. A site designed for 5–7 continuous rainy or cloudy days requires a battery bank sized on measured load, a charge controller with genuine maximum-power-point tracking, and a battery whose internal resistance remains stable at end of charge. Where MPPT conversion efficiency is specified above 99%, the harvest margin supports the autonomous period; where a PWM or derated controller is substituted, the same array may deliver 10–25% less energy and the offline period silently collapses below the design target.

The mechanical layer matters equally, because the platform's most-used offline alarm is not electrical — it is structural. Tilt, vibration, and cabinet-door alarms are only meaningful if the pole itself is dimensionally stable. The default specification should therefore be certified Q235 high-tensile structural steel (GB/T 700 / ASTM A36 equivalent), hot-dip galvanized to ASTM A123 / EN ISO 1461 with zinc coating ≥86 μm for a ≥25-year anti-corrosion design life, and engineered for 160 km/h wind gusts. An under-galvanised or unspecified-grade pole deflects and corrodes, producing false tilt events that erode operator confidence in the entire alarm channel.

Practical Field Recommendation

Write the offline test into the commissioning schedule, not the warranty period. Record the exact start time of isolation, the number of nights the schedule held, the record count returned after reconnection (expected: 96 records per pole per day at 15-minute resolution), and the clock drift. Require the integrator to demonstrate that no scheduled command was lost.

3. Core Technical Pillar 2 — Alarm Recovery: Closed-Loop Verification Under Injected Faults

Core Engineering Rule

An alarm is accepted only when the full loop is proven: detection at the edge, notification to the operator, acknowledgement logging with user identity and timestamp, and — critically — automatic clearing after the physical condition is restored. Single-direction testing (alarm appears; alarm is manually dismissed) does not constitute acceptance. Specify debounce and hysteresis explicitly: raise on ≥3 consecutive abnormal samples or ≥5 minutes; clear on ≥10 consecutive normal samples.

Physical and Electrical Rationale

Threshold alarms sit on top of electrochemical and optical behaviour that is inherently slow. A LiFePO4 pack does not fail instantaneously; cell divergence appears as a gradually widening voltage spread under load, and the early signature is rising internal resistance, not a sudden capacity drop. A platform that alarms on a single low-SOC sample will trigger during ordinary multi-day bad weather, while a platform without a divergence rule will miss the genuine degradation. Grade-A cells rated for >3,500 cycles at 80% DOD (>5,000 cycles at 50% DOD) with explosion-proof thermal relief vents provide a predictable baseline; alarm thresholds should be derived from that baseline and from the factory capacity and internal-resistance records, not from a generic default.

Optical alarms have the same dependency. A lumen-depreciation or driver-degradation alarm is only valid if the commissioning baseline is traceable to a photometric test and an IES file. LED sources specified at 170–210 lm/W with LM-80 lumen-maintenance data allow a defensible end-of-life projection; unverified bins do not.

Fault-Injection Acceptance Matrix

Practical Field Recommendation

Run fault injection on at least three poles per controller cluster, including one pole at the far end of any wireless mesh. Require the alarm log export to contain timestamp, pole ID, root-cause code, acknowledging user, and clear timestamp. Reject any platform that cannot export the clear event.

4. Core Technical Pillar 3 — Data Ownership: API, Export Rights and Firmware Control

Core Engineering Rule

The contracting authority should own all raw and derived operational data generated by the asset. The vendor retains intellectual property in firmware and platform software but grants perpetual, non-revocable export rights. Tender clauses should specify: a documented REST or MQTT API; bulk CSV/JSON export of at least 24 months of historical telemetry without per-record fees; retention for the asset design life; and full data return within 30 days of contract termination.

Physical and Electrical Rationale

Telemetry is the evidence base for warranty claims. A capacity-fade claim on a LiFePO4 pack, a lumen-maintenance claim on an LED module, or a corrosion claim on a galvanised pole all depend on continuous historical records that the authority can read independently. If the only access path is a vendor portal, the authority's negotiating position at year five is determined by the vendor's pricing at year five.

The same logic applies to firmware. Where networked solutions support firmware updates, the update process must be staged, logged, and reversible. Undocumented updates change alarm thresholds and dimming behaviour; without an audit trail, an operator cannot distinguish a genuine asset fault from a configuration change made remotely.

Practical Field Recommendation

Differentiate clearly between base capability and options. Centralised platform management, real-time lighting parameters, brightness-programme adjustment, and APP or PC control are available for selected networked solutions; 4G connectivity, local SIM hardware, and the associated data service are project options and should be priced and specified as such. Optional modules — CCTV, environmental sensing, LED display, public broadcasting, emergency call, EV charging — must expose their data through the same API and be attributed to their respective OEMs in the handover package, rather than folded into a single opaque portal.

5. Engineering Specification & Comparison Matrix

6. Verifiable Field Performance & Manufacturing Quality Assurance

Platform acceptance is credible only when the underlying hardware is traceable. MCL Solar, the international brand of Zhongshan Chengyu New Energy Technology Co., Ltd., operates a 35,000 m² specialised lighting plant in Guzhen Town, Zhongshan, Guangdong, China, with in-house capabilities covering SMT production, lithium battery pack assembly, cell sorting and capacity grading, automatic spot welding, BMS integration, battery-pack aging and charge/discharge verification, die-cast aluminium housings, CNC machining, pole fabrication and hot-dip galvanising, and smart pole system integration.

Quality-control steps relevant to platform acceptance include waterproof testing, aging testing, battery capacity and charge/discharge testing, internal-resistance checking, photometric testing, lumen measurement, IES file generation, beam-angle and CCT verification, structural inspection, corrosion-protection inspection, and final shipment inspection. These records form the commissioning baseline against which platform alarms should be thresholded.

Third-party evidence is downloadable from the MCL Solar Export Certification & Test Data Center, including UN38.3, IEC 62133, IEC 61215/61730, LM-80, CE, and RoHS reports issued by bodies such as DEKRA, IAS, NVLAP, and DTI.

Field deployments illustrate why offline and alarm logic must be tested rather than assumed. A Saudi Arabia desert highway project comprising 253 sets of 10 m and 11 m high-power poles — Q235 octagonal hot-dip galvanised poles, thermal storage enclosures rated for 55°C ambient, shipped by 40HQ sea freight container — required record buffering because backhaul across long desert corridors is intermittent. In the Philippines, an 85-set 100 W split-type installation on Cebu municipal and coastal provincial roads used ASTM B117 salt-spray defence at the seawall, while a 120-set 80 W integrated installation in Iloilo was specified for 5–7 day typhoon-monsoon endurance. In both cases, the offline test duration was tied directly to the energy-autonomy specification, not to a default value.

7. FAQ: Engineering & Tender Procurement

Q1. How long should the offline operation test run before acceptance?

Minimum 72 hours of physical WAN isolation. Where the tender specifies 5–7 days of autonomy, run the full 7 days on at least one representative pole per controller cluster. Pass criteria: no schedule loss, clock drift ≤1 s/day, and a complete interval record set (96 records per pole per day at 15-minute resolution) returned after reconnection.

Q2. What distinguishes a genuine "alarm recovery" test from a simple alarm check?

Only the full loop counts: detection, notification, acknowledgement with user identity and timestamp, physical remediation, and automatic clear. Specify debounce (≥3 consecutive samples or ≥5 minutes) and hysteresis (clear on ≥10 normal samples), then verify with injected faults — array open circuit, BMS comms loss, driver open circuit, and backhaul loss — recording both raise and clear latencies.

Q3. Who should own the platform data, and how is that enforced technically?

The contracting authority should own all raw and derived telemetry. Enforce it with a documented REST/MQTT API, bulk CSV/JSON export of at least 24 months, retention across the asset design life, and a 30-day full data return obligation on termination — with no per-record or per-report fees. Ownership without export rights is nominal.

Q4. Does every smart pole require 4G connectivity?

No. 4G hardware and local SIM data service are project options. Local scheduled control with a buffered controller is sufficient for standalone lighting operation; networked real-time parameters, brightness-programme adjustment, and APP or PC control apply to selected networked solutions. Specify connectivity per corridor based on operational need and data cost, not as a blanket requirement.

8. Conclusion: Municipal Tender Sourcing Recommendations

Platform acceptance should be treated as an engineering test protocol, not a software demonstration. Three clauses carry most of the risk:

1. Offline clause. "The local controller shall maintain the stored dimming schedule and buffer 15-minute interval data for a minimum of 72 hours — and 7 days where 5–7 day autonomy is specified — under physical WAN isolation, with clock drift ≤1 s/day and no command loss on resynchronisation."
2. Alarm clause. "Alarm generation shall use configurable debounce of ≥3 consecutive samples or ≥5 minutes; alarms shall auto-clear on restoration with a logged clear event containing timestamp, pole ID, root-cause code, and acknowledging user. Fault-injection testing on a minimum of three poles per controller cluster is a payment milestone."
3. Data clause. "The authority owns all raw and derived operational data. The contractor shall provide a documented API, bulk CSV/JSON export without per-record fees, retention for the asset design life, and full data return within 30 days of contract termination."

Pair these with hardware clauses that make the alarms meaningful: Q235 steel galvanised to ASTM A123 / EN ISO 1461 with zinc ≥86 μm, Grade-A LiFePO4 rated >3,500 cycles at 80% DOD, and MPPT conversion efficiency >99%. For the next stage, request DIALux evo calculations using the manufacturer's IES files, confirm Type II-M or Type III-M distribution against the actual carriageway geometry, and cross-check the resulting load profile against the specified autonomy days before the battery and array are frozen. Additional integration and specification resources are available at mclsolar.com.

Email: sales@mclsolar.com

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