IoT & Traffic Systems · Fixed assets
Permanent traffic signal integrations with honest, source-stamped status.
GA Applications designs integrations that present permanent traffic signal sites — cabinet, controller and communications — as one honest status picture: what the approved source reported, when, and what deserves attention. The asset owner keeps interface authority; engineering and statutory decisions stay with the people who hold them now.
For asset owners, contractors and control-centre teams who need signal-site status they can defend in a review meeting: every state carries its source, its time and its uncertainty.
The asset owner holds the interface authority
Permanent signals belong to someone — a road authority, a council, an infrastructure operator — and connecting to them happens on that owner's terms. The engagement starts by establishing who may grant interface access, which interfaces are approved, and what conditions attach. If the answer is “no documented interface”, the honest outcome is a report saying so, not a workaround.
GA Applications does not perform traffic engineering, signal design, electrical work or statutory approvals, and does not claim commissioning authority. The integration observes and reports; the people who already hold those responsibilities keep them.
Read-only-first cyber model
The first — and often only — integration direction is outward: the site publishes status, the platform consumes it. Segmentation, least-privilege credentials, logged access and no inbound path to the controller unless a separately authorised exercise ever justifies one. Monitoring is not a back door, and it is designed so it cannot quietly become one.
Source · priority · action
Every surfaced item answers three questions before anyone sees it:
- Source — which interface or system reported this, and when? No source, no display.
- Priority — what does it mean in context, under rules agreed with the owner and operator?
- Action — who is expected to do what next, and is that expectation visible to them?
A status screen that cannot answer all three is decoration, and this subsite's rule is exceptions before decoration.
Five states, defined in words before they are drawn in pixels
These definitions are agreed with the asset owner and operator during design, then applied consistently across dashboards, alerts and reports. The test of each definition is that two people looking at the same site would assign it the same state.
| State | Definition | What it does not mean |
|---|---|---|
| Normal | Approved sources reporting within expected intervals; no active warnings or faults; freshness inside the agreed window. | A guarantee about future behaviour, or a substitute for scheduled inspection. |
| Warning | A condition worth attention before it becomes a fault — e.g. an environmental or power reading outside its agreed band — with the source value shown. | A demand for immediate response; priority rules decide that. |
| Fault | The equipment or its supervising system has reported a fault condition through the approved interface. | Confirmation of the physical cause — that takes a qualified person on site. |
| Stale | Data older than its agreed freshness window, kept visible and clearly marked with its age. | Current. Stale “normal” is not normal. |
| Unavailable | No usable basis for a claim — source down, integration in maintenance, or data failed validation. | A hidden failure. Unavailable is itself an alertable event with an owner. |
Site, cabinet, controller, communications: one topology
Each site is modelled as a small system rather than a pin on a map: the intersection and its context, the cabinet and what it houses, the controller and its approved interface, and the communications path with its own health. When something looks wrong, the topology view shows where in the chain the evidence points — a controller fault report is a different event from a silent comms path, and they route to different people.
Drill-through goes from region, to site, to component, to the raw source record with its timestamp — so a claim made in a meeting can be traced to the reading that supports it, or to the gap that doesn't.
Interfaces and responsibility
Connection claims follow evidence: a suitable approved interface must be confirmed before any site is described as integrated. Signal timing, phasing and any control of the intersection remain with the traffic engineering authority. Nothing on this page — or built from it — changes who operates the network.
Four test families before the status picture is trusted
Trust is earned by trying to break the integration in controlled conditions, with the owner's people watching. Each family has an acceptance check agreed up front.
Source tests
Every value is traced back to its originating interface and timestamp. Acceptance: no displayed state exists without a source, and the trace survives an auditor clicking through unannounced.
Data-loss tests
The communications path is interrupted deliberately. Acceptance: the site transitions to stale, then unavailable, on schedule — never lingering as falsely normal — and buffered data back-fills where supported.
Maintenance tests
Planned works are simulated: the site enters a declared maintenance window with an owner and an expected end. Acceptance: maintenance silence never raises a false fault, and the window cannot quietly outlive its end time.
Restoration tests
After interruption or maintenance, return-to-normal is verified against both the data and a field observation. Acceptance: restoration is confirmed by evidence, not assumed from the first good packet.
Keep exploring
Permanent signal integration questions
Who approves connecting to a signal site?
The asset owner. Every engagement starts by establishing ownership, interface authority and the approved interfaces with their conditions. If no documented, approved interface exists for a site, that is reported plainly rather than worked around.
Does the integration change how signals operate?
No. The model is read-only-first: status flows outward to the monitoring platform, with no inbound path to the controller. Signal timing, phasing and control remain with the traffic engineering authority that holds them today.
What does “stale” mean on a signal dashboard?
Data older than its agreed freshness window. It stays on screen but is styled and labelled so it cannot be mistaken for a current reading — a stale “normal” is explicitly not treated as normal.
Can you integrate sites from different equipment generations?
Often, yes — that is precisely what the topology and registry model is for. Each site type goes through interface confirmation and a data reality check first, so the design reflects what each generation genuinely provides rather than assuming uniformity.
How is the integration verified before we rely on it?
Through four agreed test families: source traceability, deliberate data-loss, maintenance-window behaviour and evidence-based restoration. Each has an acceptance check your people witness, so trust comes from exercises, not assurances.
A status picture you can defend in the review meeting
Bring one corridor or a handful of sites. We will scope interface discovery with the asset owner and show you exactly what an honest integration would report.