Recommended direction: Use radar-video fusion at high-consequence entrances, junctions and service gates; connect validated events to approved lighting, indicator, voice and display responses while keeping routine corridor segments proportionate to risk.
AI-Driven Radar-Video Bicycle Track Safety Management 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. |
Not every pole needs a camera and not every detection needs a broadcast. Concentrate richer perception and guidance where movements conflict, authorization matters or operators need visual confirmation.
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 |
|---|---|---|---|---|
| Main public entrance | Mixed arrivals and uncertain route status. | Radar-video event plus green/yellow/red/blue status and approved welcome or warning message. | Event record, status mapping, message library and privacy boundary. | Day/night readability, audibility, event-to-scene timing and manual override. |
| Blind junction | Conflicting users approach without mutual visibility. | Overlapping detection, advance lighting and priority rule; video confirmation where justified. | Coverage drawing, conflict logic and both-direction test route. | Multi-target cases without dark gaps or contradictory indications. |
| Service gate | Unauthorized entry or large maintenance vehicle. | Vehicle event, authorized workflow and longer maintenance scene. | Access rule, operator action record and timeout setting. | Permitted and non-permitted scenarios plus recovery. |
| Race start / finish | Dense groups and scheduled event control. | Stable event scene, operator authority and controlled broadcast sequence. | Approved schedule, content and post-event restoration plan. | Group simulation, command priority and return to automatic mode. |
| Emergency point | Operator needs rapid situational awareness. | Priority event, blue status if owner-approved, voice/video instruction and lighting override. | Emergency matrix, response roles and retained event history. | End-to-end drill and communication-loss fallback. |
| Ordinary segment | Overinvestment and unnecessary personal data. | Use proportionate non-imaging sensing where it meets route risk and acceptance needs. | Risk assessment and comparison with fused alternative. | Target detection, nuisance rate and lifecycle cost. |
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 detection scope includes pedestrians, bicycles, motorcycles and four-wheel motor vehicles. For this track context, support and inspection vehicles are expected to travel within about 30–50 km/h, with bends, gradients and cyclists limiting practical vehicle speed. These operating assumptions should be confirmed by the owner before commissioning.
A sensor that detects movement does not necessarily identify vehicle type, recognize a rider, or provide a certified speed measurement. The lighting scene can respond to the approved detection input without collecting personal identity. If the project needs object classification, exact speed reporting or individual race tracking, those functions require separately specified hardware and acceptance tests.
| Target Group | Representative Field Test | Acceptance Requirement |
|---|---|---|
| Pedestrian | Slow walking, approach from different angles, brief stops. | Verify low-speed detection and ensure the standby scene remains usable when motion stops. |
| Single cyclist | Different riding speeds, clothing and bicycle profiles. | Confirm early triggering and continuous lighting across zone boundaries. |
| Group of cyclists | Closely spaced riders and sustained occupancy. | Test hold-timer renewal and simultaneous detections across several zones. |
| Motorcycle | Narrower profile and different approach geometry. | Include an actual motorcycle test; do not infer performance only from car detection. |
| Four-wheel support vehicle | Inspection, maintenance and event-support access. | Test approved 30–50 km/h operation where track rules allow, together with manual service scenes. |
Wind-driven vegetation, small animals, moving shadows, rain and adjacent traffic can produce nuisance events depending on sensor technology and installation. STSYSTEMPLC sensing settings should be configured to reduce unwanted triggers while preserving detection of legitimate track users. No sensor should be accepted solely from a claim that all interference is removed.
Begin by narrowing the sensing area to the track, avoiding nearby trees where practical and separating adjacent road traffic from cycling-zone logic. Then tune the selected sensor settings and compare occupied and unoccupied test periods. Record both missed detections and unwanted triggers so the owner can see the trade-off.
| Nuisance Source | What to Examine | How to Verify |
|---|---|---|
| Vegetation in wind | Sensor field includes moving branches or grass. | Adjust aiming and coverage; compare windy unoccupied periods with pedestrian and cyclist passes. |
| Small animals | An animal crosses near the sensing area. | Review available filtering and target settings; confirm slow human detection remains reliable. |
| Rain, dust or fog | Environmental conditions differ from dry commissioning. | Test relevant weather conditions and use a documented fallback scene for uncertain sensing. |
| Adjacent road vehicles | A nearby road shares the sensor field. | Separate coverage and zone mapping; verify that remote traffic does not brighten the whole track. |
| Simultaneous users | Several legitimate targets occupy overlapping zones. | Maintain the occupied scene and prevent one clear sensor from overriding another active zone. |
An ordinary evening, a crowded training session and an organized race do not need identical dimming behavior. The operator should be able to select an approved scene with a clear scope, start time, end time and restoration rule. Event control should be available through authorized local operation as well as the agreed platform.
During a race, steady lighting through occupied competition segments may take priority over occupancy savings. During quieter periods, local detection can raise selected zones while the rest remain at the approved background level. Maintenance scenes should identify the working area and preserve visibility for approaching riders.
| Scene | Lighting Policy | Trigger or Authority | Acceptance Focus |
|---|---|---|---|
| Daily operation | Background lighting with occupied-zone uplift. | Sensor events, renewed hold time and gradual return. | Verify minimum scene and route continuity. |
| Dense training | Extended occupied scene over active zones. | Repeated detections keep the scene active. | Avoid premature dimming between groups. |
| Organized race | Stable event illumination through the approved route. | Authorized event schedule or local override. | Record selected zones, approval and return to normal. |
| Inspection or repair | Local working scene and approaching-route visibility. | Maintenance authorization and work-order reference. | Record operator, affected assets and closure. |
| Weather scene | Approved brightness and CCT for the weather condition. | Weather input or authorized manual selection. | Measure visibility, glare and scene recovery. |
| Communication interruption | Stored local schedule and approved sensing behavior. | External-network failure policy. | Demonstrate continuity and later record synchronization. |
Key entrances, exits and junctions can be equipped with an integrated radar-video unit to strengthen visual safety management and refine zone dimming. Radar supplies supported movement information, while video gives operators a view of the scene. Together, they can help the owner understand how cyclists, pedestrians and authorized service vehicles share critical access points.
Deploy these units at priority locations and combine them with distributed track sensors. Through the selected device’s supported event or metadata interface, a project integration can link validated occupancy, direction or speed information to CH-800 Gateway zone rules. The lighting response can prepare the approach, hold busy junctions at the approved scene and return gradually to the agreed background level.
Use live video and available radar information to review approaching users, conflicts and event conditions at entrances and crossings.
Adapt the affected zone’s approved brightness, advance-lighting group and hold time to validated activity information and operator authority.
Link source events, scene commands and available video references so the owner can review what happened and how the lighting responded.
Radar-video integrated monitoring reference: at key entrances, exits and junctions, the selected radar-video unit can combine supported movement information with live visual review. Through the specified interface, validated events can support CH-800 Gateway zone control, advance lighting, occupied-scene hold time and operator review.
| Priority Location / Situation | Visual Management Value | Dimming and Scene Linkage | Site Acceptance Check |
|---|---|---|---|
| Main entrances and exits | Combine radar target information with live video for a clearer view of movement through the access point. | Raise the entry, crossing and connected approach zones to the approved occupied scene before users enter. | Test both travel directions with pedestrians, bicycles, motorcycles and four-wheel service vehicles. |
| Crossings and converging routes | Help operators review interacting movements and dense activity at junctions. | Keep the junction and selected neighboring segments raised while occupancy continues. | Verify detection overlap, simultaneous targets, hold-time renewal and a stable junction scene. |
| Dense cycling groups | Use supported occupancy or traffic-flow information to help operators understand sustained use. | Select a stable group-use scene rather than repeatedly dimming between closely spaced riders. | Validate the selected device’s counting or occupancy capability; compare field activity with recorded events. |
| Authorized service vehicles | Use supported direction and speed metadata with video to review vehicle access. | Apply an approved service-access scene to the affected zones, with controlled restoration afterward. | Confirm target capability, event fields and authorized scene priority for the installed configuration. |
| Abnormal movement or incident review | Link available analytics events with visual confirmation by the operator. | Allow an authorized operator to raise the affected area or invoke an approved priority scene. | Specify supported event types; test alarm source, video reference, operator action and closure. |
| Quiet periods and sensor faults | Provide a live view when available and distinguish valid low occupancy from lost detection. | Return gradually to the approved background level after the clear period; retain an approved fallback scene on sensor or link failure. | Test lost metadata, video interruption, external-network loss and restoration without unsafe dimming. |
The selected radar-video model, analytics and interface determine the available target information and event functions. Specify and test the integration before delivery. Brightness limits remain within the approved photometric scenes, and local lighting continues according to the agreed fallback rules if video or analytics becomes unavailable.
At main entrances, crossings, event-control points and emergency access locations, the system can combine red, yellow, green and blue indicators with voice broadcast and visual information displays. This gives riders, pedestrians, service teams and operators a shared local message while CH-800 Gateway rules coordinate the related lighting zones.
The four colors should follow the owner’s approved operating rules and local traffic or event standards. Their meaning, priority and permitted automatic actions are defined before commissioning so the same color does not carry different meanings at different locations.
Normal route operation, approved direction or an open access point. Maintain the normal occupied lighting scene and display routine route information.
Caution for dense rider flow, reduced visibility, temporary work or an approaching service vehicle. Raise the selected zone and issue the approved caution message.
Stop, no-entry, incident or emergency restriction under the approved operating plan. Activate the priority scene and direct users away from the affected zone.
Information, service support, inspection, medical or event-organization guidance as defined by the owner. Identify the responsible access point or assistance route.
| Guidance Channel | Application at the Track | Lighting and Control Linkage | Acceptance Evidence |
|---|---|---|---|
| Four-color indicator | Give an immediate local status at entrances, crossings, controlled sections and service points. | CH-800 selects the approved zone scene, brightness and hold time associated with the status rule. | Color meaning table, priority logic, day/night visibility check, manual override and restoration test. |
| Recorded voice broadcast | Play pre-approved multilingual messages for caution, route closure, weather, service access or event instructions. | A validated event can call the approved message and lighting scene for the affected zone. | Message list, language, audibility, delay, repetition limit and event-to-message mapping. |
| Live voice announcement | Allow an authorized control-room or on-site operator to address a selected entrance or route segment. | Operator can combine the announcement with a local priority lighting scene where permitted. | Account role, zone selection, microphone path, volume limit, activity log and return-to-normal procedure. |
| LED information display | Show route status, direction, weather caution, event timing or temporary access information. | Display content and lighting zones use the same approved event identity and operating status. | Content templates, readability distance, brightness control, time synchronization and fallback message. |
| Video guidance screen | Present safety instructions, route maps, emergency guidance or operator-approved live / recorded visual information at key hubs. | The selected video or instruction can accompany a priority scene without changing unapproved route lighting limits. | Source authorization, display-zone mapping, content priority, interruption behavior and operator record. |
| Mobile or platform notification | Notify authorized maintenance, event and emergency teams of the same confirmed status. | Alarm, scene command, broadcast action and maintenance response remain connected in the event record. | Recipient roles, timestamp alignment, acknowledgement and closure record. |
Color meanings and broadcast actions are project rules, not universal defaults. Automatic messages and scene changes should use confirmed inputs, approved priorities and a tested manual override. Video access, recording and retention follow the owner’s operating 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. |
Communication should be selected from the actual power layout and terrain. PLC can use suitable existing power conductors, while LoRA can provide a wireless route where the electrical network does not offer a reliable common communication path. A dual-channel design can provide an alternative route when one channel is degraded.
For selected STSYSTEMPLC hybrid configurations, 0.1 s channel takeover is a project performance target to demonstrate in the specified test conditions. Record direction of transfer, load, interference condition and end-to-end lighting behavior. A working communication backup also needs powered field devices; a backup data path does not restore power to an unpowered luminaire.
| Review Item | PLC | LoRA | HYBRID PLC & LoRA |
|---|---|---|---|
| Existing lighting conductors | Useful where feeder topology and noise permit reliable PLC. | Independent of a common conductor communication path. | Use each channel according to measured site quality. |
| Mixed or irregular supplies | Different transformers and feeder boundaries can complicate communication. | Useful where pole power originates from different circuits. | Survey feeder boundaries and provide wireless coverage where required. |
| Terrain and wireless shadowing | Does not depend on direct wireless visibility, but depends on conductors. | Coverage may need gateway placement or additional route planning. | Validate bends, cuttings and gateway overlap on both channels. |
| Cable interruption or strong electrical noise | Affected conductor route may become unavailable. | Alternative data path can continue where devices remain powered. | Demonstrate PLC-to-LoRA transfer under the agreed fault condition. |
| Wireless interference or lost coverage | A healthy conductor route can remain available. | Affected wireless route may become unavailable. | Demonstrate LoRA-to-PLC transfer under the agreed condition. |
| Single-route dependency | One principal field path. | One principal field path. | Alternative field paths with documented priority and recovery logic. |
| Commissioning scope | Measure conductor quality, feeder limits and device density. | Measure RF coverage, noise, terrain effects and local regulatory settings. | Test both routes separately, then fault transfer and recovery together. |
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.
| Interruption | Expected Local Behavior | Record and Recovery |
|---|---|---|
| Internet or cloud unavailable | Approved local schedule and field scenes continue within the configured architecture. | Remote visibility is unavailable; retain local records where supported. |
| One field communication channel unavailable | Use the tested alternative route where the hybrid configuration and power allow. | Record channel status, transfer result and failed devices. |
| Sensor uncertain or unavailable | Apply the approved default scene rather than an untested reduction. | Flag the sensor or zone for inspection and preserve a usable route scene. |
| Gateway unavailable | Lamp-level behavior follows the configured fallback capability. | Document the scene retained at each controller and the restoration procedure. |
| Grid supply interrupted | 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.
Detection counts with weather and zone context.
Recommend a site inspection or settings review; preserve legitimate low-speed detection.
Scene history, input power and event schedules.
Check sustained occupancy, configuration changes or an electrical fault.
Alarm source, repair history and replacement records.
Identify patterns for maintenance planning and root-cause review.
Aggregated zone activity at the agreed reporting level.
Adjust future scheduling only after lighting and operator review.
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.
Route segment, pole ID and affected device.
Asset map and fault source.
Fault type, current scene and route impact.
Alarm timestamp, severity and operator assessment.
Assigned team, access window and work scope.
Work-order reference and maintenance responsibility.
Part replacement, wiring action or configuration correction.
Part identity, settings version and service record.
Lighting and sensing return to the approved behavior.
Functional retest and status feedback.
Owner can review the completed action and future follow-up.
Closure time, confirmation and recurring-fault history.
Radar-video integration, colored status indications and broadcast control 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.
Length, width, curves, gradients, entrances, rest areas and pole locations.
Owner / consultant confirms geometry and operating constraints.
Pedestrians, cyclists, group density and authorized service vehicles.
Confirm event hours, vehicle permissions and approved speeds.
Required scenes, photometric criteria, CCT and environmental conditions.
Approve luminaire configuration and scene performance.
Existing supplies, civil-work scope and backup requirements.
Define grid, hybrid or solar responsibilities by segment.
Sensors, gateway zones, PLC / LoRA routes and platform policy.
Confirm local autonomy and each integration interface.
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
住所 : F4,Bldg A, Hanzhong Industrial Park, No.67, North of Xinsha Ave, Xin Tang, Zeng Cheng, Guang Zhou, China
tel : +86 20 8278 0427
Eメール : info@stsystemplc.com
Eメール : morrison426@163.com
