CENTRAL PLATFORM GUIDE
Turn a successful laboratory connection into a repeatable field integration that can be deployed across intersections.
Published August 31, 2026 · GAOQIAO Traffic Technology
Integration begins with a shared interface baseline
A central-system integration is ready for deployment only when commands, telemetry, alarms, time synchronization, security and recovery have been tested against the same controller release. A dashboard connection is a useful milestone, but it is not proof that field behavior is safe and supportable.
Freeze the endpoints and identities
Record controller model, hardware revision, firmware build, protocol revision, device identifier, network address, central-platform version and test environment. Define how a replacement controller receives the correct identity without cloning credentials or losing the maintenance history.
Validate every direction of data flow
| Flow | Examples | What to verify |
|---|---|---|
| Controller to centre | Mode, plan, stage, detector state, alarms, door/power status | Units, timestamp, update trigger and stale-data behavior |
| Centre to controller | Plan selection, time update, permitted configuration commands | Authorization, preconditions, acknowledgement and audit log |
| Event delivery | Conflict, lamp/output fault, restart, communications loss | Priority, deduplication, clear condition and operator text |
Test time and schedule behavior
Verify time zone, daylight-saving policy where applicable, clock drift, synchronization source and behavior after power loss. Run plan changes across midnight, week boundaries and exceptional calendars. The central platform and controller should show the same effective schedule and event time.
Test failure and recovery deliberately
Under an approved controlled test procedure, test loss of network, controller and central-service restarts, delayed messages and unit replacement. Protect live traffic from test effects. Verify the required local safe operation, stale-status marking, alarm retention and recovery behavior against the agreed specification. Confirm that reconnection does not repeat commands in a way that could create unsafe operation.
Close with a deployable commissioning record
The final record should include versions, configuration checksum, test IDs, exceptions, packet traces, screenshots, responsible engineers and approval. Reuse that record as the template for each intersection so the rollout team does not invent a new process in the field.
Frequently asked questions
When is a controller-to-centre integration complete?
It is complete when the agreed commands, status points, alarms, timestamps, permissions and recovery cases pass on the released hardware and firmware. The result should be repeatable from a written procedure and leave a configuration and test record for the specific controller identity.
Should the controller keep operating when communications fail?
The required behavior must be defined by the project and safety design, but network loss should not create uncontrolled output behavior. Test the approved local fallback, alarm generation, stale-data indication and reconnection sequence rather than assuming the controller and central platform recover correctly.
Why test controller replacement as an integration case?
Replacement testing can reveal identity, credential, configuration and history issues that a laboratory connection test may miss. A documented swap test should check whether field staff can install a spare, restore the approved plan and reconnect it without duplicate identities or untracked configuration changes under the tested conditions.
Related buyer resources
- Controller Protocol Documentation Package
- Traffic Light Remote Monitoring Guide
- Controller Compatibility Checklist