Тел : +86 20 8278 0427
Электронное письмо : info@stsystemplc.com
Up to 92% Power Saving becomes believable only when every lighting point can be commanded, reported and verified. Every smart light needs a communication path. Why pay for a second one when the power cable already reaches every pole? For long roads, tunnels, bridges and existing HPS feeder networks, the wrong communication design can turn an IoT lighting project into recurring SIM fees, excessive gateways, dead zones, slow alarms and maintenance calls the owner cannot verify.
PLC is not a decorative protocol name. In the right electrical topology, it lets the lighting system use the existing power line as the field data path between cabinet, circuit and lamp. The procurement question is not "PLC or wireless?" The real question is whether the project has an engineered communication route that can still command, report and recover when the road is dark, wet, noisy, remote or underground.
Roadway and tunnel lighting is usually organized by electrical feeders, cabinets, circuits and pole groups. PLC is valuable because it follows that same physical structure: the power cable that energizes the lamp can also carry control and status data when the feeder condition, noise level, coupling method, cabinet boundary and gateway placement are engineered correctly. This makes PLC especially relevant for long corridors, tunnels, bridges, expressways and existing municipal lighting circuits where adding a separate communication network can increase cost and maintenance complexity.
PLC is not automatically the best route everywhere. Old urban districts with mixed power sources, undocumented wiring, crowded poles and many telecom lines may favor LoRA or a hybrid design. STSYSTEMPLC therefore treats PLC as one part of a procurement architecture: survey the feeder, test the route, define the fallback rule and prove command-feedback behavior during FAT and SAT.
93 km Shenzhen Outer Ring Expressway: real on-site footage filmed by our team. Two high-speed trains traveling at 350 km/h each cross beside an 800 kV ultra-high-voltage network. HYBRID PLC & LoRA operated normally in this project environment. Validate the new site's proposed topology through its own acceptance tests.
IoT lighting still needs PLC because the lighting power network is already the owner’s most complete field infrastructure. A separate wireless-only design may work well in many places, but it can add coverage surveys, gateway density, subscription planning and signal-shadow risk. PLC uses the feeder itself as the route for lamp control and status feedback when the electrical network is suitable.
The owner buys smart luminaires, but the road still depends on whether every lamp can receive commands and return status from the field.
The existing power line already reaches the luminaire. PLC can reduce the need for separate field communication routes where feeder topology is clean.
Survey feeder conditions, use CH-800, test PLC route quality and apply LoRA fallback where PLC alone is not the strongest answer.
Smart lighting is often sold from the platform screen: map view, fault alarm, power consumption report and work order. But every one of those functions depends on a lower field layer. A map cannot dim a lamp unless a command reaches the controller. A fault alarm is not useful unless the controller can report back. A power consumption dashboard is not credible unless the electrical boundary is understood.
PLC sits close to the physical lighting network. It does not begin with a telecom subscription; it begins with the feeder that already belongs to the lighting system. That is why PLC keeps appearing in roadway and tunnel lighting tenders even when wireless technology is widely available.
| Platform Promise | Field Condition Required | Why PLC Matters |
|---|---|---|
| Map-based lamp control | Each lamp controller must have a stable command path. | The feeder route can become the field communication path where topology is suitable. |
| Fault alarm | The controller must return status from the pole to the gateway. | PLC can carry feedback along the same electrical network that defines the affected circuit. |
| Power consumption report | Cabinet, circuit and lamp identities must be reconciled. | PLC encourages the project to respect electrical boundaries instead of only drawing map icons. |
| Scene dimming | Groups must follow road zones, tunnel zones and feeder limits. | A PLC design naturally forces the owner to examine cabinet and circuit grouping. |
| Work order closure | The repaired lamp must be verified by data, not only by a crew note. | A command-feedback loop helps connect physical repair to owner records. |
Lighting control does not normally require video bandwidth. It requires a trustworthy route for commands, status, alarms, schedules and exception records. A lighting owner needs to know whether the correct lamp received the correct command and whether its status changed after the command. For this type of data, route certainty and acceptance evidence matter more than marketing speed.
A PLC lighting route must therefore be evaluated like an electrical communication path. The EPC should identify the cabinet boundary, feeder length, cable type, branch structure, coupling point, noise source, surge environment, distribution transformer boundary and maintenance access. If those items are not checked, the owner is not buying an engineered PLC system; the owner is only buying a protocol label.
Which cabinet and circuit own the lamp? The answer determines command grouping, fault classification and field responsibility.
Drivers, old ballasts, cable joints and nearby power equipment can affect the signal route and must be tested.
The owner should require a command-feedback demonstration on supplied controllers before citywide rollout.
PLC is strongest when the lighting system has a recognizable feeder structure and the project owner wants to reuse existing electrical infrastructure. Long corridors, tunnel lighting, bridge approaches, expressways, industrial roads and organized municipal feeders are often good candidates for review. The reason is simple: the power cable is already installed, protected, maintained and connected to the lamp.
The best PLC projects do not assume perfection. They survey representative circuits, test electrical noise, confirm controller compatibility and document exceptions. A few difficult circuits may be handled by LoRA or a hybrid route while the rest of the corridor uses PLC efficiently.
| Project Condition | Procurement Advantage | STSYSTEMPLC Design Response |
|---|---|---|
| Long expressway corridor | Many lamps follow the same road and cabinet structure. | Use feeder-based route planning and CH-800 local control zones. |
| Tunnel lighting | Power and lighting zones are highly structured. | Match PLC route, luminance input, emergency priority and scene file by tunnel zone. |
| Bridge and approach lighting | Wireless shadows and maintenance access can be difficult. | Use PLC where feeder route is stable and LoRA fallback where structure creates RF or cable risk. |
| Existing HPS retrofit | The power network already reaches every light. | Replace lamp/driver/controller while retaining usable feeder infrastructure. |
| Industrial or port road | Metal structures and equipment may affect wireless coverage. | Test both PLC and LoRA, then assign the route by zone rather than by slogan. |
A good PLC article must be honest: PLC is not a magic solution for every city. In many older districts, road-lighting power is not cleanly organized. Some lamps may be powered from old feeders, nearby buildings, small transformers, mixed public and residential sources or undocumented repairs. Poles can carry many unrelated cables from electricity, telecom, internet and monitoring operators. In those environments, LoRA or HYBRID PLC & LoRA may become more practical.
This is especially true where infrastructure has served for 20 to 30 years or longer and has been modified repeatedly. If the electrical route is not reliable as a data path, the owner should not force PLC only to satisfy a specification line. The engineering route should follow the field condition.
| Field Condition | PLC Risk | Better Procurement Response |
|---|---|---|
| Old urban power network | Unknown feeders and repairs can make route behavior unpredictable. | Survey sample circuits; use LoRA or Hybrid where feeder confidence is low. |
| Poles carrying many unrelated cables | Electrical and electromagnetic environment may be difficult to control. | Separate lighting communication acceptance from visual pole inspection. |
| Mixed ownership of power sources | Owner may not control the full route. | Define ownership boundary before selecting communication technology. |
| Frequent emergency repairs | Future cable changes can change PLC performance. | Require configuration backup, retesting procedure and route documentation. |
| Short scattered road sections | PLC savings may not outweigh survey and integration work. | Use wireless or cabinet-level control where it is simpler and accountable. |
The strongest procurement decision is not to defend one protocol everywhere. It is to assign each field route to the environment where it works best. PLC is attractive when the power feeder is a strong asset. LoRA is attractive when the power route is messy but wireless coverage is practical. HYBRID PLC & LoRA is strongest when the lighting asset is critical enough that a single path is not enough.
| Decision Factor | PLC | LoRA | HYBRID PLC & LoRA by STSYSTEMPLC |
|---|---|---|---|
| Best environment | Structured feeders, corridors, tunnels and known cabinet boundaries. | Old urban retrofits, scattered poles and difficult power wiring. | Critical corridors, tunnels, high-mast areas and projects requiring route redundancy. |
| Main cost logic | Reuse existing power cable as a data route. | Reduce dependence on power-line quality. | Reduce single-path risk and avoid overbuilding one communication method everywhere. |
| Main risk | Noise, feeder complexity and undocumented electrical changes. | RF shadows, gateway placement and interference. | Requires engineered route design and acceptance testing for both paths. |
| Failure response | Needs a defined fallback if the PLC route weakens. | Needs a defined fallback if wireless route weakens. | PLC weakens → LoRA can take over; LoRA interference → PLC can preserve operation, subject to project design. |
| Procurement evidence | Feeder survey, route test, command-feedback record. | Coverage survey, gateway plan, interference check. | Both route tests, CH-800 rule file, controller feedback and SAT demonstration. |
A street-lighting tender often mixes several things in one sentence: communication protocol, dimming interface, gateway network and control philosophy. PLC, LoRA, NB-IoT and CAT-1 are communication routes. RS485, DALI and DALI-2 are field-bus or driver-control interfaces in many projects. Loop dimming is a cost-saving circuit-level control strategy. They are not the same layer, so the procurement table must compare where each method fits instead of treating all names as substitutes.
| Method | Best-Fit Use | Main Advantage | Main Limitation | STSYSTEMPLC Procurement View |
|---|---|---|---|---|
| PLC | Structured feeders, tunnels, expressways, bridges and existing lighting circuits. | Uses the existing power line that already reaches the lamp. | Needs feeder survey, noise control and route acceptance. | Use where cabinet and feeder topology is suitable; prove command-feedback by circuit. |
| LoRA | Old urban retrofits, scattered poles, messy power routes and wireless-friendly roads. | Does not depend on the power-line route for field data. | Requires gateway planning, RF coverage review and interference consideration. | Use where old power wiring makes PLC uncertain; verify coverage and gateway density. |
| HYBRID PLC & LoRA | Critical corridors, tunnels, high-mast areas, bridges and high-reliability infrastructure. | Two engineered field paths reduce single-route exposure. | Requires documented topology, fallback rules and acceptance tests. | Preferred route for critical lighting: PLC weakens → LoRA can take over; LoRA weakens → PLC can preserve operation, subject to project design. |
| NB-IoT | Low-data remote monitoring where operator network coverage is strong and latency is acceptable. | Uses public cellular IoT infrastructure and can reduce owner gateway construction. | Depends on operator coverage, module availability, service policy and network behavior. | Use selectively for suitable remote assets; do not rely on it for every fast local scene or tunnel priority requirement. |
| CAT-1 | Gateway uplink, anti-theft monitoring, remote cabinets, solar-grid assets and 24-hour online reporting when powered. | Stronger data capacity than low-rate IoT links and practical for direct cloud communication. | Requires SIM/service planning, power budget and operator coverage. | Strong for CH-800 uplink, cabinet telemetry and anti-theft / asset-status reporting; define recurring cost and battery-backed behavior. |
| RS485 | Shorter wired control runs, cabinets, tunnel equipment rooms and controlled electrical environments. | Stable and familiar industrial wired communication when cabling is controlled. | Requires dedicated wiring, controlled bus topology and installation labor. | Good inside cabinets or controlled local systems; less attractive for long pole-by-pole retrofits unless cable is already provided. |
| Loop Dimming | Tunnels and roadway sections where circuit-level dimming is enough and cost control is critical. | Can reduce controller quantity and installed cost by controlling groups/circuits. | Does not provide individual lamp intelligence unless combined with other devices. | Very strong cost route for many tunnel lighting systems; use when group-level control meets the lighting and maintenance requirement. |
| DALI | Driver-level digital dimming in controlled installations, buildings, cabinets or selected outdoor projects. | Standardized driver control with addressable dimming potential. | Outdoor long-distance wiring, surge exposure and installation complexity must be reviewed carefully. | Useful at driver/interface level where wiring and environment support it; not a substitute for corridor-wide communication architecture. |
| DALI-2 | Projects needing stronger standardized device behavior and ecosystem compatibility. | Improved interoperability framework compared with older DALI implementations. | Still requires wiring, compatible devices and project-specific outdoor protection. | Review for controlled zones and high-spec interfaces; define how it connects to CH-800, PLC/LoRA route and platform records. |
Lighting feeders are not laboratory cables. They can include branches, joints, different conductor conditions, switching devices, drivers, surge events and electrical noise. A simple narrow communication path can become fragile when a frequency band becomes noisy. Parallel multi-channel OFDM PLC is valuable because it can use multiple subcarriers and channel behavior rather than depending on one fragile tone.
For procurement, the owner does not need to become a modem engineer. The owner needs to ask whether the proposed PLC route has been designed for real field noise, whether the gateway and controller can maintain useful communication under representative conditions and whether route performance is proven on supplied equipment.
| Technical Point | Plain Procurement Meaning | Acceptance Evidence |
|---|---|---|
| Multiple subcarriers | The communication path can tolerate some noisy frequency areas better than a single narrow route. | Show stable command-feedback results on representative circuits. |
| Parallel channel behavior | The system has more route resilience when feeder noise changes. | Test different scene commands, status reads and fault records during site conditions. |
| Feeder-aware design | PLC must be matched to electrical topology, not only listed in a brochure. | Provide cabinet/circuit map, coupling plan and route-quality report. |
| Gateway coordination | The field layer must connect to CH-800 and platform records. | Demonstrate input → gateway decision → field command → controller feedback → owner record. |
The price of a smart lighting system is not only the controller. A wireless-only design may require more gateways, more signal surveys, more SIM planning, more subscription review or more battery-backed communication equipment. A PLC route can reduce some of those burdens where the existing feeder is suitable. The savings are not automatic; they come from project-specific route engineering and from avoiding duplicated infrastructure.
In long corridors, the hidden cost often appears after commissioning: the owner discovers unreachable lamps, incomplete fault reports, unclear cabinet boundaries or expensive recurring network costs. PLC can reduce that exposure when it is aligned with the electrical system the maintenance team already understands.
| Cost Line | Wireless-Only Exposure | PLC-Based Reduction Route |
|---|---|---|
| Gateway density | More gateways may be needed to cover shadows and long corridors. | Use feeder route where suitable and reserve wireless gateways for difficult zones. |
| Recurring data cost | Large deployments can accumulate SIM or network service charges. | Keep many field commands on the lighting feeder and connect upstream through planned gateways. |
| Field troubleshooting | Signal problems may be separated from electrical records. | Tie communication route to cabinet, circuit and lamp identity. |
| Maintenance dispatch | Crews may visit without knowing whether the fault is power, device or communication. | Classify the fault boundary before dispatch and verify closure afterward. |
| Expansion | New zones may require fresh coverage planning. | Use a repeatable feeder-survey method for expansion phases. |
Power saving is not created only by replacing a lamp. The strongest savings usually come from a complete chain: high-efficacy LED, accepted dimming schedule, motion or traffic response, ambient or weather logic, and verified operating records. If the communication route is weak, the owner may have to keep lights at a conservative output, disable adaptive scenes or send crews to check conditions manually. That weakens the business case even when the luminaire itself is efficient.
This is why PLC belongs in the energy discussion. The system cannot prove reduced power consumption if it cannot confirm which lamps which scene, when they changed level, and whether exceptions were caused by safety rules, faults or communication loss. A project claiming up to 92% power saving must be able to show how the communication layer supports the scene plan behind that number.
| Energy-Saving Layer | Communication Requirement | PLC / HYBRID Value |
|---|---|---|
| High-efficacy LED replacement | Owner must know which asset was replaced and commissioned. | Lamp identity is tied to cabinet, circuit, controller and platform record. |
| Scheduled dimming | Groups must receive the correct scene at the correct time. | Feeder-based groups can follow road sections and cabinet boundaries. |
| Motion or traffic response | Sensor event must reach the correct lighting zone without confusing adjacent roads. | CH-800 can coordinate approved local logic while PLC/LoRA routes carry the command. |
| Weather or tunnel priority | Safety scenes may override ordinary energy-saving scenes. | Hybrid route and local rules help preserve priority behavior when one path is weak. |
| Power consumption report | Scene hours, exceptions and electrical boundaries must be traceable. | Grid → Cabinet → Circuit → Lamp structure supports credible reporting. |
PLC alone is not the system. The gateway and control logic decide how field communication becomes a manageable lighting service. CH-800 is positioned as the local control and gateway layer connecting field controllers, approved scenes, sensor inputs, cabinet boundaries and platform records. In a PLC route, CH-800 helps convert electrical feeder structure into controllable lighting zones.
The owner should confirm what happens when the external network is interrupted. The system should preserve approved local behavior where the project design supports it, then synchronize records when connectivity returns. This is where a smart lighting system becomes more than a cloud dashboard.
| Layer | Duty | Owner Verification |
|---|---|---|
| Field controller | Receives dimming command and returns supported status. | Command one lamp and read back the resulting state. |
| PLC route | Carries commands and data over suitable lighting power lines. | Test representative cabinet and circuit conditions. |
| CH-800 | Applies approved local rules and coordinates field communication. | Demonstrate schedule, sensor input, manual command and fallback behavior. |
| IoT Lighting Platform | Displays assets, alarms, power consumption records and maintenance workflow. | Open map, alarm, energy report and work-order records for selected assets. |
| Owner handover | Preserves settings, accounts, exports and recovery files. | Test backup, restore and operator role change before final acceptance. |
A useful communication architecture should be tested through real operating scripts, not only normal ON/OFF commands. Roads and tunnels have different priorities: some scenes are energy-saving scenes, some are safety scenes, some are maintenance scenes and some are emergency override scenes. The communication design must support all of them.
These scripts help the owner see whether PLC is being used as a field engineering layer. The same structure can be used during FAT, representative site testing and final SAT.
| Scenario | What the Owner Should Trigger | What Must Be Observed | STSYSTEMPLC Acceptance Focus |
|---|---|---|---|
| Late-night low traffic | Apply scheduled dimming to a selected road zone. | Correct lamps enter the approved level and return status. | CH-800 scene file, PLC route, controller feedback and power record match. |
| Vehicle detection | Trigger motion or traffic input before the vehicle reaches the zone. | Advance lighting rises, holds for the approved delay and returns safely. | Sensor-to-gateway-to-controller chain is demonstrated with timestamps. |
| Tunnel portal daylight change | Change luminance input or simulate the accepted threshold. | Portal lighting scene follows safety hierarchy, not a simple energy schedule. | Priority rule, local control and communication route are verified together. |
| Fog or harsh weather | Trigger weather scene where the project includes weather input. | Lighting output or CCT changes only in approved zones. | Weather input, zone boundary, controller response and recovery record are retained. |
| Communication weakness | Simulate a weak PLC route or wireless route in a controlled test. | Fallback behavior occurs without losing approved local operation. | HYBRID PLC & LoRA route behavior and recovery record are shown to the owner. |
| Maintenance repair | Create a lamp/controller fault and then restore it. | Alarm opens, work order is linked and closure is verified by device status. | Fault-to-closure chain is proven from map to physical lamp. |
Many HPS retrofit projects already have cabinets, feeders, poles and maintenance routes. The owner may not want to rebuild the road only to make lighting intelligent. PLC is attractive because it can add a communication layer on top of the existing power infrastructure when the feeder condition is suitable. That makes it especially useful for projects where the owner wants modernization without unnecessary civil work.
However, HPS retrofits also carry inherited risks: old ballasts, aging cable joints, uncertain circuit records, changed pole numbers and maintenance history that may not match the actual field. A serious PLC design uses the retrofit survey to clean up these records. In that sense, PLC does more than communicate; it forces the project to rebuild the owner’s electrical truth.
| HPS Retrofit Condition | Risk if Ignored | PLC-Oriented Engineering Response |
|---|---|---|
| Old cabinet labels | Map records may point crews to the wrong circuit. | Reconcile cabinet, circuit and pole IDs during controller commissioning. |
| Mixed lamp ages | Energy baseline and failure pattern are hard to compare. | Create a new asset record linked to the installed controller and luminaire. |
| Old ballasts and drivers | Electrical noise or interface mismatch can damage communication confidence. | Test representative routes and replace incompatible equipment during retrofit. |
| Incomplete maintenance files | The owner cannot prove whether the smart upgrade improves service. | Use alarms, work orders and verified closure to rebuild the maintenance record. |
| Existing feeder reused | The project may assume the route is good without evidence. | Treat feeder testing as a procurement deliverable before rollout. |
A PLC proposal should be reviewed by evidence, not by a protocol checkbox. The owner should ask for a route map, equipment schedule, controller model list, gateway placement, noise-test method, fallback sequence and SAT script. The answer should be project-specific enough that the EPC team can install and test without guessing.
| Procurement Question | Weak Answer | Acceptable Answer |
|---|---|---|
| Which circuits use PLC? | "All lights support PLC." | A cabinet/circuit map identifies PLC zones, exceptions and fallback zones. |
| How is feeder quality checked? | "The product has long distance communication." | Representative route test, noise review and command-feedback report are included. |
| What happens if PLC weakens? | "It should work." | A defined LoRA or local fallback behavior is tested and recorded. |
| How is the lamp identified? | "The platform has a map." | Pole, controller, circuit, cabinet and gateway identity are reconciled. |
| How is completion accepted? | "Installation is finished." | FAT/SAT demonstrates command, feedback, alarm, scene, report and recovery. |
This non-affiliated comparison uses common market positioning as a procurement reference. It does not claim product equivalence, partnership or identical scope. Compare the exact offered models, interfaces, local support, acceptance evidence and lifecycle ownership.
| International Brand | Typical Buyer Association | Comparison Focus | STSYSTEMPLC Procurement Standard |
|---|---|---|---|
| Siemens | Infrastructure automation, cabinets and transport-system integration. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Schneider Electric | Power distribution, energy management and control architecture. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| ABB | Electrification, automation and field-device integration. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Signify / Philips Interact | Connected lighting points and city-scale lighting management. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Schreder | Roadway and tunnel luminaires with connected-control ecosystems. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Itron | Utility-scale networks, metering context and smart-city operations. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Telensa | Wide-area street-light control and city-scale node management. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Flashnet inteliLIGHT | Remote lighting management and multi-network integration. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Tvilight | Sensor-led adaptive street lighting and connected-lighting controls. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| Lucy Zodion | Street-lighting cabinets, photocells, nodes and field controls. | Compare the offered boundary for feeder topology, electrical-noise tolerance, local fallback and command-feedback proof. | Require model-specific documents, interfaces, FAT/SAT evidence and owner handover. |
| STSYSTEMPLC | CH-800, PLC, LoRA, Hybrid PLC + LoRA, sensing, loop/RS485 options and IoT Lighting Platform. | Can the proposed PLC Communication route be proven on supplied hardware before rollout? | Present topology, command, feedback, fallback, energy records and maintenance closure for the representative zone. |
Alongside supplier reputation, field-proven engineering experience helps owners understand delivery scope. These references provide engineering context for roadway, bridge and tunnel projects; the scope and acceptance evidence for a new project should be reviewed separately.
Factory testing and site acceptance should not stop at "the light turns on." The owner must see the complete communication chain. A useful test starts with one lamp and one circuit, then expands to a representative group and a difficult zone. The same test should be repeatable by the EPC and understandable by the maintenance contractor.
| Test Stage | What to Demonstrate | Pass Evidence |
|---|---|---|
| Bench test | Controller, driver and gateway communicate using the specified interface. | Model numbers, wiring, command response and supported feedback are recorded. |
| Representative circuit | PLC route works on a real cabinet/circuit condition. | Command success, status feedback, alarm record and route-quality note. |
| Difficult zone | Noise, distance, branch or environmental challenge is tested. | Exception record and fallback method are accepted by the owner. |
| Hybrid fallback | LoRA or local rule behavior is verified when PLC is weak or interrupted. | Timestamped event: route change, command recovery and record synchronization. |
| Handover | Owner can operate, export, back up and restore the system. | Accounts, configuration file, training record and maintenance procedure are complete. |
Many weak smart-lighting projects fail before installation begins because the tender language is too abstract. "PLC supported" is not enough. "Wireless supported" is not enough. "Cloud platform included" is not enough. The owner needs a communication architecture that names the physical route, fallback route, device boundary, data boundary and acceptance method.
The buyer selects PLC before confirming feeder quality. A survey-first method prevents overpromising and protects the owner.
The platform shows lamp icons, but the cabinet and circuit records do not match. Maintenance then becomes slow and expensive.
The project has a communication path but no accepted behavior when that path weakens. Critical roads need a tested fallback method.
The owner cannot export assets, alarms and configuration after handover. This creates long-term vendor dependence.
The system passes a small easy test, then struggles in difficult field zones. A representative sample protects the rollout.
The alarm appears, but the system cannot prove restoration. IoT lighting must close the loop, not only open alarms.
| Question | Short Answer | Procurement Detail |
|---|---|---|
| Is PLC always cheaper than wireless? | No. PLC can reduce duplicated field communication cost where the feeder is suitable. | Compare installed cost, gateway count, recurring network cost, survey cost and maintenance cost by zone. |
| Does PLC need a clean power line? | It needs an engineered and tested route, not a perfect theoretical line. | Noise, feeder length, branch structure and coupling must be checked on representative circuits. |
| Can PLC work in tunnels? | It can be strong in tunnels because lighting zones and power routes are often structured. | Tunnel priority scenes, luminance inputs and fallback rules must be tested, not assumed. |
| Why not use LoRA everywhere? | LoRA is valuable, especially in old or messy power environments, but it still needs coverage planning. | Gateway placement, RF shadows, interference and ownership of the network layer must be reviewed. |
| Why use HYBRID PLC & LoRA? | Critical infrastructure should not depend on one field route when two engineered routes are practical. | The acceptance test should show fallback behavior, recovery and synchronized records. |
| Can PLC prove energy saving? | PLC does not save energy by itself; it helps execute and verify energy-saving scenes. | Power consumption reports must link scene hours, exceptions, meter boundaries and lamp records. |
| What should the owner receive after handover? | More than a platform login. | Asset exports, topology files, configuration backup, restoration method, account roles and maintenance process. |
The final decision should be made by zone. A city may use PLC for long structured corridors, LoRA for old urban sections and HYBRID PLC & LoRA for critical tunnels, high masts or difficult infrastructure. This is not a compromise; it is the normal engineering answer when the field environment changes by road segment.
| Field Scenario | Suggested Route | Why |
|---|---|---|
| New or organized expressway feeder | PLC or HYBRID PLC & LoRA | Feeder structure can support route planning; hybrid adds resilience for critical zones. |
| Long tunnel with defined lighting zones | HYBRID PLC & LoRA | Tunnel operation is critical; dual route and CH-800 local logic protect acceptance. |
| Old urban road with mixed wiring | LoRA or Hybrid by exception | Electrical route may be uncertain; wireless route may be cleaner if coverage is proven. |
| Bridge or high-mast area | HYBRID PLC & LoRA | Access difficulty and infrastructure risk justify communication redundancy. |
| Small scattered retrofit | LoRA or cabinet-level control | PLC survey cost may not be justified if the lighting assets are scattered. |
| Industrial road with heavy electrical noise | Test both before deciding | Do not assume; measure PLC noise and wireless coverage before procurement. |
Before the tender is released, the owner should define what must be proven. This prevents bidders from hiding behind protocol names and helps procurement compare complete delivery boundaries.
| Required File | Purpose | Minimum Content |
|---|---|---|
| Cabinet and circuit map | Defines the electrical structure behind the communication design. | Cabinet, circuit, lamp group, feeder route and ownership boundary. |
| Controller compatibility list | Prevents interface mismatch. | Driver model, dimming interface, feedback support and installation method. |
| Communication topology | Shows PLC, LoRA, gateway and platform boundaries. | Route by zone, gateway location, fallback behavior and exception handling. |
| FAT/SAT script | Turns promises into pass/fail evidence. | Command, feedback, alarm, scene, report, fallback and restoration tests. |
| Handover package | Protects the owner after the EPC leaves. | Accounts, exports, backup, restore method, training record and service procedure. |
Each public reference answers a different procurement concern: a long crossing, an undersea tunnel, demanding corridor communication and mass terminal deployment. A new owner can use these settings to challenge the proposed architecture while keeping earlier infrastructure operating files under the original owner's control.
| Public Reference | Infrastructure Duty | Question for the New EPC Project | STSYSTEMPLC Engineering Position |
|---|---|---|---|
| 55 KM Hong Kong-Zhuhai-Macao Bridge | Long bridge-and-tunnel crossing, described as one of the Seven Wonders (1 of 7 Wonders); investment near USD 20 billion. | Can the scheme link power, cabinets, circuits, zones and maintenance over an unusually long crossing? | Use the 55 km reference as a scale anchor; design and accept the new project's exact field boundaries separately. |
| Shenzhen-Zhongshan Link | Sea-crossing link with an 8-lane undersea tunnel, investment near USD 6.7 billion, and distinct portal, interior and incident duties. | How are tunnel luminance, local priority scenes and control-room authority coordinated? | Use the sea-crossing tunnel reference to frame the new tunnel-zone design and EPC interface review. |
| 93 KM Shenzhen Outer Ring Expressway | Roadway/tunnel corridor with the real filmed crossing of two 350 km/h trains beside a dense 800 kV network. | What happens to approved lighting scenes when the field communication route is stressed? | HYBRID PLC & LoRA operated normally in the filmed project setting; validate the offered topology on the new site. |
| 177 KM Guangfozhao Expressway | Approximately 28,000 field terminals distributed across a 177 km expressway reference. | Can the EPC address, commission, maintain and reconcile many devices without losing asset identity? | Use the deployment scale to design staged zone acceptance, data mapping and owner handover for the new scope. |
Company case materials also cite 2,600+ tunnels, over 3,000 km of infrastructure and approximately 65% of China's expressway-tunnel coverage. Each new tender still receives its own equipment schedule and acceptance plan. Earlier infrastructure owners' operational files are not disclosed publicly.
A city does not need PLC because PLC sounds technical. A city needs PLC when the power feeder is the most reliable and economical way to reach every lighting point. It needs LoRA when the power route is too uncertain or wireless is the cleaner field path. It needs HYBRID PLC & LoRA when lighting continuity, tunnel safety, long-corridor reliability or maintenance accountability makes a single route too fragile.
For STSYSTEMPLC, the practical answer is route engineering: survey the field, match PLC and LoRA to the correct zones, let CH-800 preserve approved local behavior and prove the full loop from command to feedback to owner record.
For a roadway, street or tunnel lighting project, prepare one representative cabinet and circuit sample. Test PLC route quality, LoRA coverage, controller feedback, CH-800 local scene behavior, platform records and fault-to-closure workflow before approving the citywide communication architecture.