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
Disconnect the network, restart the controller, restart the central service, introduce delayed messages and replace a unit. Confirm local safe operation continues, stale status is marked, alarms are not lost and the connection recovers without repeated unsafe commands.
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 exposes identity, credentials, configuration and history problems that a laboratory connection can hide. A documented swap test proves that field staff can install a spare, restore the approved plan and reconnect it without duplicating identities or leaving an untracked configuration.
Related buyer resources
- Controller Protocol Documentation Package
- Traffic Light Remote Monitoring Guide
- Controller Compatibility Checklist