-
Tel : +86 20 8278 0427
-
Correo electrónico : info@stsystemplc.com
Tel : +86 20 8278 0427
Correo electrónico : info@stsystemplc.com
Resolve these inputs before equipment selection and quotation comparison.
Compare equal equipment, software, civil work, commissioning, training, spares and service boundaries before ranking bids.
Include instruments, route trials, repeated tests, corrective work, evidence files and owner witnessing rather than treating SAT as a one-line allowance.
Track energy, alarms, patrol effort, dispatch, repair, closure time and configuration changes so lifecycle claims remain reviewable.
Owner accounts, exports, maps, backups, interface notes, spare strategy and restore procedures must survive a change of contractor.
Recommended direction: Compare lifecycle responsibility, not only purchase price. Require a cost boundary, FAT/SAT scripts, asset identity, configuration control, alarm closure, spare planning, training and owner-held exports before award.
Bicycle Track Lighting Lifecycle Cost, FAT/SAT and Owner Handover should be evaluated as an operating system, not as a collection of impressive devices. The proposal must connect every important claim to a route drawing, configuration, calculation, test method or owner-held record. Define responsibility between the owner, consultant, EPC, luminaire supplier, field-control provider and any video, power or communication partner before procurement.
| Decision | Recommended Basis | Evidence Before Award | Acceptance Outcome |
|---|---|---|---|
| Operating boundary | Define users, zones, speed policy and priority scenes. | Route plan, control narrative and responsibility matrix. | Correct zones respond in normal and abnormal scenarios. |
| Field layer | Select sensing, luminaires, controllers and mounting from site inputs. | Coverage, photometric and electrical documentation. | Installed behavior matches approved configuration. |
| Communication | Choose PLC, LoRA or hybrid from topology and survey evidence. | Route map, channel test and recovery logic. | Commands, alarms and records survive agreed faults. |
| Local continuity | Store approved schedules and fallback scenes locally. | Offline boundary and restoration procedure. | Safe local operation continues within declared limits. |
| Handover | Transfer accounts, maps, backups, logs and maintenance rules. | Handover index and owner access test. | Owner can inspect, export and restore the system. |
A low equipment price can become an expensive operating system when route data, spares, server responsibility, communication surveys or acceptance work are omitted. Cost comparison should align scope and evidence before ranking suppliers.
Use this matrix during concept review, tender clarification and pilot planning. Values shown in a proposal remain design inputs until the selected hardware, route geometry and operating policy are verified.
| Zone / Condition | Primary Risk | Engineering Direction | Owner Evidence | Acceptance Focus |
|---|---|---|---|---|
| Equipment supply | Lowest price may exclude gateways, sensors, licenses or required interfaces. | Normalize bill of materials, options, quantities and exclusions. | Priced scope and compliance schedule. | Delivered models and configuration match award. |
| Installation / commissioning | Unclear responsibility causes repeated site work. | Assign wiring, addressing, aiming, survey, integration and test roles. | Responsibility matrix and method statements. | Signed installation and commissioning records. |
| Software / data | Owner may lose access after subscription or contractor change. | Declare hosting, retention, roles, exports, APIs and backup ownership. | Data schedule and account handover plan. | Owner export, restore and access demonstration. |
| Maintenance | Fault alarms without closure workflow do not reduce OPEX. | Connect alarm, diagnosis, dispatch, repair, verification and closure. | Alarm dictionary, spare list and service levels. | Injected fault through completed closure. |
| Upgrade / replacement | Obsolete devices or undocumented settings create lock-in. | Maintain configuration backups, interface notes and migration strategy. | Version register and compatible replacement process. | Restore and representative replacement test. |
| End-of-life / expansion | Future zones may require new capacity and responsibilities. | Reserve addressing, gateway capacity and documented expansion boundaries. | Capacity table and lifecycle roadmap. | Controlled addition without disrupting accepted zones. |
The matrix is deliberately route-based. Nominal ranges, wireless distances, battery capacities or analytic features should not be copied into a tender as achieved performance without the related design assumptions.
The bicycle track lighting and safety management system links motion detection with neighboring lighting zones. When an approved target enters a sensing area, the current segment and selected segments ahead rise to their agreed lighting scene. The occupied scene remains active while detections continue; brightness returns gradually to the approved standby scene after the hold period expires.
The system should be judged by safe scenes, local fallback, alarm traceability and owner-held records. A useful evidence chain includes CH-800 Gateway zones, FAT/SAT files, offline tests, communication-route records, alarm logs, maintenance closure and configuration backups. AI-assisted analysis becomes useful when these field records are dependable.
Sensor reports movement within the configured field of view.
Target direction, coverage, mounting height and nuisance sources are checked on the track.
Gateway or local group logic raises the selected segments ahead.
Neighbor map, response time and uninterrupted visibility are demonstrated in both directions.
Further detections renew the occupied scene and hold timer.
Continuous groups do not cause premature dimming or repeated brightness oscillation.
The zone returns to its approved background scene after the clear period.
Standby illumination and transition rate match the approved lighting design.
Events, commands, energy and faults are retained according to the project scope.
The owner can inspect source identity, timestamps and configuration version.
A straight-road sensor layout cannot simply be repeated along every bend. Curves, crests, cuttings, trees and retaining walls may hide approaching riders from a sensor mounted farther down the track. Place detection and lighting zones around the real sightline, with overlap where a person may disappear briefly behind terrain.
On downhill sections, the illumination sequence should follow the approved rider-speed envelope and the available sight distance. On uphill sections, a slow cyclist or pedestrian must not fall below a speed threshold that was chosen only for vehicles. At sharp bends, maintain a stable background scene and test the approach from both directions.
Detection may occur too late if a sensor sees only the exit.
Add upstream sensing and overlap; illuminate the visible approach and curve before entry.
Terrain can interrupt line of sight; speeds differ uphill and downhill.
Use separate approach zones and test both slow uphill targets and faster downhill riders.
Repeated motion can keep a route occupied for long periods.
Refresh the hold timer; use continuous scenes during sustained occupancy.
Pedestrians and cyclists can enter from a side path.
Include cross-path sensing and a junction scene, rather than only longitudinal detection.
A person may stop moving while still needing light.
Use a persistent safe scene or suitable presence logic; do not rely only on motion pulses.
Motorcycles or four-wheel vehicles may join the track.
Provide manual priority and service scenes with an approved access policy.
The system connects sensing inputs, individual light controllers, cabinet or supply zones, CH-800 Gateway / Centralized Controller logic and the selected management platform. The owner receives a route map that relates a physical pole to its controller, circuit, gateway and operating scene.
Cloud access can support remote management where permitted. On-premises servers, Ethernet or fiber can support an owner-controlled management environment. The local field-control layer should retain the approved behavior when external connectivity is interrupted; loss of remote visibility should be distinguishable from loss of illumination.
| System Layer | Operating Role | Owner-Held Evidence |
|---|---|---|
| Sensor layer | Report approved movement or environmental inputs. | Coverage plan, mounting detail, settings and detection test record. |
| Optional radar-video unit | Provide supported target events / metadata and visual review at key access points through the specified integration. | Model and interface scope, time alignment, zone-event mapping, video-access roles and fallback test. |
| Status and broadcast layer | Provide approved four-color indications, recorded / live voice announcements, LED information and video guidance at selected locations. | Status dictionary, message and content library, priority map, zone linkage, operator roles and interruption behavior. |
| Lamp controller | Execute dimming, CCT scenes and selected local fallback. | Device identity, command feedback, scene limits and firmware reference. |
| Cabinet / supply zone | Organize power responsibility and local operating inputs. | Circuit map, isolation procedure, supply status and manual authority. |
| CH-800 Gateway | Coordinate route zones, stored rules and field records. | Zone map, configuration backup, event history and offline behavior. |
| Communication route | Carry field commands and status through the selected channels. | Coverage measurements, path records and measured recovery behavior. |
| Platform and owner files | Review alarms, energy, maintenance and configuration. | Account roles, exports, retention policy and handover package. |
Separate luminaire efficacy from occupancy control. A more efficient luminaire reduces power for a stated output. Dynamic lighting changes the time spent in each operating scene. Dense cycling traffic may keep most zones raised, so savings should be modeled from route occupancy rather than from a universal percentage.
Agree the baseline and reporting boundaries before acceptance. Records should identify which meters or controller measurements are used, how event nights are treated, and whether communication or standby consumption is included. The owner should be able to reproduce the monthly result from accessible records.
| Energy Factor | What Changes the Result | Evidence to Retain |
|---|---|---|
| Luminaire efficiency | Compare complete-luminaire watts at the required photometric design. | Output report, input-power report, CCT, optics and operating temperature. |
| Occupied hours | Determine how long zones remain in the raised scene. | Detection history, hold-time settings and group-occupancy samples. |
| Background scene | Define permitted dimming and the required minimum illumination. | Approved scene file and measured track lighting at the selected level. |
| Race or event operation | Treat event nights separately from ordinary schedules. | Event authorization, affected zones and operating hours. |
| Total system energy | Include agreed controller, gateway and standby loads. | Measurement boundary, meter identity and reconciliation method. |
| Owner review | Retain the data needed to repeat the comparison. | Exported records, report formula, baseline dates and configuration changes. |
International brands offer different combinations of luminaires, sensors, networks and management software. Compare the actual proposed system, including partner-supplied devices. A controller platform has no luminaire lm/W value of its own, and an advertised family maximum does not describe every installed variant.
The examples below use manufacturer product pages and documentation. They help frame a practical comparison; they are not a ranking or a claim that any brand lacks functions outside the cited product. Use the same route layout, target tests and lighting requirement for all proposals.
| Brand / Reference | Sensor and Control Scope | Published Efficacy Basis | Track Procurement Check |
|---|---|---|---|
|
Signify / Philips LumiStreet gen2 example Official product reference |
DALI interface in the cited variant; confirm the proposed external sensor and zone logic. | 167 lm/W in a published 26 W / 4,350 lm variant. | Compare the selected optic and CCT, then demonstrate bicycle and motorcycle approaches. |
|
Schréder IZYLUM NEO / EXEDRA route Official product reference |
Selected product pages list an optional motion sensor; confirm the supplied configuration. | Confirm the exact model datasheet; no family-wide figure is assigned here. | Request sensor coverage, neighbor-zone behavior and model-specific photometric files. |
|
Tvilight CitySense Plus Official product reference |
PIR sensing with neighboring-light triggering; published pedestrian, bicycle and car detection. | Control / sensor product; lm/W belongs to the paired luminaire. | Check motorcycles, dense groups, bends and local fallback against the proposed configuration. |
|
Thorn Isaro Official product reference |
Confirm the control interface and any sensor option in the local supply proposal. | Official brochure lists up to 180 / 189 lm/W by size. | Compare the local variant, CCT, optic and temperature rating; confirm connected sensing scope. |
|
Fagerhult Evolume 75 Post Official product reference |
Published as suitable for footpaths / cycle paths, with a sensor option. | 157 lm/W shown on the official product page. | Request the selected sensor, installation geometry and luminaire test configuration. |
|
TRILUX Jovie IQ Official product reference |
D4i / Zhaga interfaces support the selected control integration. | Up to 190 lm/W stated for the product family. | Confirm installed sensor, interface compatibility, track optic and zone-response acceptance. |
|
Telensa Telecell / PLANet Official product reference |
Wireless lighting control and CMS; confirm any track-motion input and local scene integration. | Control platform; use the paired luminaire report. | Clarify sensor scope, local occupancy scenes, export rights and ongoing service responsibilities. |
|
Itron CityEdge networked lighting Official product reference |
Networked lighting control and a sensor / partner ecosystem; verify the selected track sensor. | Controller / network route; use the paired luminaire report. | Request the sensor-to-light test, gateway / network failure behavior and energy-data boundary. |
|
Flashnet / inteliLIGHT Smart streetlight controllers Official product reference |
Controller interfaces and sensor-enabled lighting operation; specify the actual detector. | Controller / software route; use the paired luminaire report. | Define field scenes, sensor integration, communications, local autonomy and owner handover files. |
|
Dimonoff Lighting nodes, gateway and platform Official product reference |
Connected lighting management with sensor integrations; verify track-specific motion hardware. | Control / platform route; use the paired luminaire report. | Check route grouping, sensor responsibility, commissioning scope and record access. |
Pedestrians, cyclists, motorcycles and four-wheel service vehicles, with configurable sensing settings and route-specific acceptance.
Up to 230 lm/W option, subject to the selected complete luminaire, optics, CCT and test conditions.
CH-800 Gateway zones, PLC + LoRA selection, local fallback, FAT/SAT and owner-held maintenance records.
For STSYSTEMPLC and every alternative, request the same evidence: exact luminaire configuration, detector model, two-direction route test, nuisance-event results, local fallback demonstration, energy measurement boundary and a complete handover package.
A long bicycle track can involve several contractors: civil works, poles, supply circuits, luminaires, communications, software and event operations. Define the interfaces early so a fault does not become an unresolved dispute between the lamp supplier, sensor supplier and network team.
STSYSTEMPLC can organize these responsibilities around the field-control chain and the owner’s operating scenes. The proposal should identify what is supplied, what is integrated, who tests each boundary and which records the owner receives. This makes the comparison concrete before the project is awarded.
| Owner Problem | Likely Coordination Gap | STSYSTEMPLC Project Response |
|---|---|---|
| Sensor detects, but next bend remains dim | Detection and neighboring-zone rules were specified separately. | Map each input to the current and advance zones, then demonstrate real traversal. |
| Track is occupied, but lights dim too early | Hold time or repeated-trigger behavior does not suit dense groups. | Test sustained groups and keep the occupied scene until the agreed clear period. |
| Remote screen shows offline | The operator cannot tell whether lamps are dark or only disconnected. | Separate supply faults, field communication faults and external-network status. |
| Different feeder supplies along the corridor | Communication design assumes one uniform electrical network. | Survey actual feeders and select PLC, LoRA or hybrid paths zone by zone. |
| Energy-saving statement cannot be checked | Baseline or measurement scope was not agreed. | Provide measured scene power, operating history and owner-accessible reports. |
| New maintenance contractor lacks files | Configuration remains with the original team. | Deliver asset maps, backups, interface notes and acceptance records. |
External network failure should not make an occupied track wait for a cloud command. Store the approved scene and schedule behavior in the selected local controllers and CH-800 Gateway configuration. Define how sensing, manual override and abnormal-condition scenes operate during an interruption.
The exact fallback depends on which part fails. Loss of the internet, loss of the gateway, loss of one field channel and loss of luminaire power are different events. Test them separately and record the visible lighting behavior, retained events and return-to-normal sequence.
Approved local schedule and field scenes continue within the configured architecture.
Remote visibility is unavailable; retain local records where supported.
Use the tested alternative route where the hybrid configuration and power allow.
Record channel status, transfer result and failed devices.
Apply the approved default scene rather than an untested reduction.
Flag the sensor or zone for inspection and preserve a usable route scene.
Lamp-level behavior follows the configured fallback capability.
Document the scene retained at each controller and the restoration procedure.
Only the agreed backed-up circuits or solar / battery units continue.
Measure reserve and restored status; do not treat communication redundancy as energy backup.
AI-Driven review can help operators examine repeated faults, unusual energy patterns, zones with frequent nuisance triggers and maintenance trends. The useful input is a consistent field record, not an attractive dashboard alone. Each event should be associated with the correct sensor, pole, controller and zone.
AI analysis should support operating decisions while approved local lighting rules remain available independently. The owner should know which data is analyzed, how recommendations are reviewed and who can authorize configuration changes. Anonymous zone activity can support occupancy analysis without implying personal rider tracking.
| Review Task | Required Data | Practical Operator Action |
|---|---|---|
| Repeated nuisance triggers | Detection counts with weather and zone context. | Recommend a site inspection or settings review; preserve legitimate low-speed detection. |
| Unexpected energy use | Scene history, input power and event schedules. | Check sustained occupancy, configuration changes or an electrical fault. |
| Repeated device faults | Alarm source, repair history and replacement records. | Identify patterns for maintenance planning and root-cause review. |
| Occupancy trend | Aggregated zone activity at the agreed reporting level. | Adjust future scheduling only after lighting and operator review. |
| Configuration drift | Approved files compared with the active version. | Flag unapproved changes and support documented restoration. |
Factory Acceptance Testing should prove configuration and integration before delivery. Site Acceptance Testing should prove the real route with its bends, slopes, vegetation, electrical supplies and permitted traffic. Both stages should produce records the owner can inspect and retain.
Agree test routes and pass criteria before installation. Include the slowest approved user, both directions, side entrances, continuous groups and service vehicles. Repeat representative tests with normal scenes, event scenes and the agreed interruption cases. A short straight-line demonstration is insufficient for a varied cycling corridor.
| Acceptance Item | FAT Before Delivery | SAT on the Track | Owner-Held File |
|---|---|---|---|
| Asset identity | Map sensor, pole, controller, cabinet and gateway identifiers. | Check random physical assets against route and platform records. | Asset list, route map and zone table. |
| Target coverage | Define supported targets and sensing settings. | Test pedestrians, bicycles, motorcycles and four-wheel vehicles. | Target-pass records and installed settings. |
| Bend and gradient | Prepare zone overlap and advance-lighting rules. | Traverse both directions at approved speeds and difficult approaches. | Route test, scene sequence and response timing. |
| Dense groups | Verify repeated-trigger and hold-timer logic. | Test sustained groups and simultaneous zone occupancy. | Detection history and no-premature-dimming result. |
| Radar-video linkage, where supplied | Confirm supported targets, analytics events, metadata interface and lighting-zone mapping. | Test entrance / junction activity, video and event alignment, scene commands, dimming limits and lost-input fallback. | Integration scope, event / command log, visual reference and recovery record. |
| Indicators and broadcast | Approve color meanings, messages, visual content, event priorities and zone mappings. | Test each indicator, recorded / live voice path, display content, lighting linkage, manual override and communication interruption. | Status matrix, message library, content approval, audibility / readability checks and event record. |
| Nuisance filtering | Prepare sensitivity, coverage and available filter settings. | Compare occupied and unoccupied periods with relevant nuisance sources. | Missed / unwanted trigger records and adjustments. |
| Photometric scenes | Validate luminaire configuration and approved scene limits. | Measure relevant light levels, uniformity and glare evaluation. | Photometric files and site measurement report. |
| PLC / LoRA routes | Verify both channels and fault-transfer logic where supplied. | Interrupt each channel and measure behavior under agreed conditions. | Route quality, transfer timing and recovery record. |
| Outside-network loss | Load local schedules, scenes and fallback rules. | Disconnect the external link and observe field operation. | Offline result, retained logs and restoration record. |
| Weather / dual CCT | Check selected 2700K ↔ 6000K rules and manual override. | Verify trigger, scene, recovery and measured output. | CCT scene file and weather-input test. |
| Power reserve | Agree backed-up scope and consumption assumptions. | Test selected outage and charging / reserve behavior. | Power test and reserve calculation. |
| Alarm closure | Prepare alarm dictionary and work-order fields. | Simulate a fault through dispatch, repair and closure. | Alarm log and maintenance closure report. |
| Owner handover | Prepare accounts, exports, backups and spare-part plan. | Confirm owner access and a practical restore demonstration. | Handover index, configuration backup and restoration result. |
A long track benefits from fault location at the physical asset level. The maintenance team should know whether the issue belongs to a sensor, luminaire, controller, power circuit, gateway or communication route. A generic offline icon leaves too much work for field inspection.
Close each job with the repair action, replaced part, configuration change and restored operating status. Keep the history accessible to the owner so a new contractor can understand recurring faults without rebuilding the project from memory.
| Maintenance Step | Practical Requirement | Record to Retain |
|---|---|---|
| Locate | Route segment, pole ID and affected device. | Asset map and fault source. |
| Assess | Fault type, current scene and route impact. | Alarm timestamp, severity and operator assessment. |
| Dispatch | Assigned team, access window and work scope. | Work-order reference and maintenance responsibility. |
| Repair | Part replacement, wiring action or configuration correction. | Part identity, settings version and service record. |
| Verify | Lighting and sensing return to the approved behavior. | Functional retest and status feedback. |
| Close | Owner can review the completed action and future follow-up. | Closure time, confirmation and recurring-fault history. |
A 5-year warranty and a 7-, 8- or 10-year operating plan are different commitments. Compare warranty scope, labor responsibility, component availability, software support, battery replacement and access to project data separately. Any extended service or energy-management arrangement should be defined in the signed contract.
The owner needs continuity through changes in firmware, server arrangements, spare parts and maintenance contractors. Configuration backups and documented interfaces reduce dependence on the original commissioning team. Planned operating life is supported by maintainable hardware and usable files, not by a year count alone.
| Review Stage | Operating Decision | Evidence to Request |
|---|---|---|
| Year 1 | Verify the installed route, seasonal conditions and representative operating scenes. | Accepted configuration, defect closure, energy baseline and training record. |
| Year 5 | Review warranty boundaries, component aging and maintenance history. | Warranty record, replacement plan, battery review where used and updated backups. |
| Year 8 | Review support, software continuity and contractor transition capability. | Interface notes, spare-part availability, restore test and owner exports. |
| Year 10 | Decide which components to retain, refurbish or replace. | Lifecycle cost, recurring faults, lighting performance and migration plan. |
Lifecycle cost, acceptance and owner handover requires disciplined claim control. Separate completed project facts, verified product capability, route-specific design proposals and assumptions that remain open. This protects the owner from treating a reference video, maximum rating or simulated result as proof of the complete installed outcome.
| Evidence Grade | Meaning | Required Wording |
|---|---|---|
| A — Project verified | Identifiable delivered scope supported by acceptance or owner records. | State the project, scope and verified result. |
| B — Product verified | Selected product capability supported by a current datasheet, certificate or controlled test. | State model, configuration and limits. |
| C — Design proposal | Route-specific calculation and control narrative awaiting site acceptance. | Use “proposed” or “subject to SAT”. |
| D — Validation required | An assumption materially affects cost, safety or performance. | Name the owner, due date and validation method. |
BANYIN Freeway: project reference for sensor-related coordinated field lighting. Transfer the engineering method and request the applicable scope; bicycle-lane targets, route scenes, response timing and operating outcomes remain subject to this project’s FAT/SAT.
Apply the same discipline to every major statement. Sensor configuration is not route permission; communication redundancy is not backup power; maximum efficacy is not maintained track performance; AI-assisted review is not personal rider tracking. Every conclusion must point to evidence the owner can retain after handover.
Project information for system design: route length, bends and gradients, pole spacing, power access, rider density, event operating modes and permitted service vehicles can be translated into lighting zones, sensor locations, communication routes, operating scenes and FAT/SAT acceptance criteria.
A useful proposal starts with a route plan rather than a fixed sensor count. Segment the track by geometry, user density, event use, electrical access and communication quality. Confirm the number and position of poles through the photometric design, then align sensing and gateway zones with those segments.
For a 150 km-class corridor, phased commissioning can reduce uncertainty. Begin with representative bends, slopes, dense-use areas and remote power segments; resolve settings and acceptance criteria there before extending the same approved method. This is a deployment approach, not a claim that a named 150 km project has already been delivered.
| Proposal Input | Information Needed | Approval Responsibility |
|---|---|---|
| Route inputs | Length, width, curves, gradients, entrances, rest areas and pole locations. | Owner / consultant confirms geometry and operating constraints. |
| Traffic inputs | Pedestrians, cyclists, group density and authorized service vehicles. | Confirm event hours, vehicle permissions and approved speeds. |
| Lighting inputs | Required scenes, photometric criteria, CCT and environmental conditions. | Approve luminaire configuration and scene performance. |
| Power inputs | Existing supplies, civil-work scope and backup requirements. | Define grid, hybrid or solar responsibilities by segment. |
| Control inputs | Sensors, gateway zones, PLC / LoRA routes and platform policy. | Confirm local autonomy and each integration interface. |
| Acceptance inputs | Target tests, interruption tests and owner file index. | Agree measurable FAT/SAT criteria before procurement. |
Share the route length, bends and gradients, pole spacing, electricity access, user density, permitted service vehicles, weather exposure, communication conditions and owner acceptance requirements. STSYSTEMPLC can organize the architecture, zone plan and evidence package for technical review.
Discuss the ProjectOpen Video/PDF Download Hub
Habla a : F4,Bldg A, Hanzhong Industrial Park, No.67, North of Xinsha Ave, Xin Tang, Zeng Cheng, Guang Zhou, China
Tel : +86 20 8278 0427
Correo electrónico : info@stsystemplc.com
Correo electrónico : morrison426@163.com
