IoT & Traffic Systems · Fleet
Temporary traffic lights that can report their own deployment story.
GA Applications designs a monitoring layer for temporary traffic light fleets: which units are assigned to which job, for what window, in what state, with what power and communications health — plus the field evidence of what happened when someone had to drive out. Traffic-control decisions stay with qualified traffic professionals.
For traffic-management businesses running portable signal sets across shifting roadworks, where the daily questions are operational, not theoretical: is the set on site, is it running, and did anyone notice when it wasn't?
The problem this solves — and its limits
Portable signal fleets fail quietly. A set can be hit, go flat or lose comms hours before anyone drives past, and the “system” that finds out is often a member of the public. The target operating outcome is simple: the fleet tells you first, the alert has an owner, and the response leaves evidence.
A good fit when
- You run multiple portable signal sets across concurrent jobs and depots.
- Set-up, shift-change and removal checks are done but not captured where coordinators can see them.
- Power, comms and fault events surface late, or arrive without site context.
- You want service history per unit — controller and accessories — to inform maintenance and replacement.
Not the right tool when
- You need the traffic management plan itself — that remains with qualified traffic professionals; this layer references the approved plan, it never authors or approves it.
- You want to change signal behaviour remotely — that is a separate, gated control exercise, never part of monitoring by default.
- You need the lights themselves supplied or serviced — GA Applications designs the digital layer, not the hardware.
Assignment and the deployment window
Every monitored set is assigned to a job with a deployment window: where it should be, from when, until when, under which approved-plan reference. That context changes what the data means. A voltage alert at 11:47 inside a live window is urgent; the same reading in the depot on Saturday is a maintenance task. Without the window, both look identical.
The registry holds the unit's identity — controller, signal heads, stands, batteries, charging gear and comms module — so an alert names the actual equipment, and a coordinator can see which accessories went out and whether they all came back.
Readiness before the window opens
A readiness view answers the night-before question: which sets are confirmed ready for tomorrow's jobs — charged, comms checked, accessories complete, no open faults — and which are not. Readiness is a checklist with evidence, not a green dot someone clicked.
What one set's record links
- → Job 1187 · northbound taper · window 06:00–18:00
- → Approved-plan reference TMP-1187-REV-C (held by the traffic contractor)
- → Controller SN-4471 · firmware recorded at last service
- → Accessories: 2× head, 2× stand, battery pack B-88, comms module
- → State: Connected last seen 42s ago
- → Open items: none · last fault: charging connector, March
Connected, degraded, offline — and what raises an alert
Three state families cover a portable set's life, each with its own alert rules agreed during design. State always carries source and freshness; a set that has gone silent is shown as offline with its last known state, never as quietly healthy.
| Class | Example trigger | Default owner | Notes |
|---|---|---|---|
| Power | Supply voltage below agreed floor; charge source lost | Coordinator on duty | Escalates if unacknowledged inside the agreed window during a live deployment. |
| Comms | No contact beyond 2× expected interval | Operator → coordinator | Treated as its own event: silence ≠ fault, and last known state stays visible and labelled. |
| Fault | Device-reported fault flag via the approved interface | Coordinator + maintainer | What the equipment actually reports depends on the confirmed interface — verified at discovery, not assumed. |
| Context | Set outside its assigned window or expected position | Coordinator | Catches “wrong place, wrong time” problems that pure telemetry misses. |
Arrival, intervention, return: the field loop
When an alert needs boots on the ground, the response is structured the same way every time: assigned with asset history attached, arrival recorded against the job, intervention documented with checks and photos, and return-to-service confirmed by a person — then reviewed by a supervisor before closure. The set's record absorbs all of it, so next month's fault on the same unit comes with context.
Field workflows support evidence and coordination. They do not replace emergency procedures, competent supervision, or the duties that apply around live traffic — those remain exactly where they are today.
- 06:02 · SET-UPDeployment check-in
Crew confirms set placed per the approved plan reference; photo attached to the record. (Illustrative scenario.)
- 11:47 · ALERTVoltage low during live window
Rule fires, alert raised with site context, acknowledged by the coordinator in four minutes.
- 12:40 · ARRIVALMaintainer on site
Arrival logged against job and asset; history shows a March charging-connector fault on this unit.
- 13:25 · INTERVENTIONCause found and fixed
Charging lead replaced; checks and photos attached; status returns to connected.
- 18:10 · RETURNEnd of window confirmed
Set removed and return confirmed with photo; day record closes for supervisor review.
Proven with exercises, not promises
Before the fleet depends on the system, the system is exercised — with your people, your units and your call-out habits. Each stage has an acceptance check agreed in advance.
Bench exercise
A unit on the bench is put through power loss, comms loss and fault conditions. Acceptance: every condition surfaces correctly, with source and freshness, and nothing healthy-looking hides a failure.
Field exercise
A supervised deployment runs the full window: check-in, a staged alert, field response, restoration evidence, return. Acceptance: the record matches what your crew says actually happened.
Response exercise
An after-hours scenario tests escalation: unacknowledged alerts step up, owners are named, closures require evidence. Acceptance: your team runs the loop without us in the room.
Where the boundaries sit
GA Applications designs the monitoring and evidence layer. Traffic management plans, signal placement, site safety and any interaction with live traffic remain with qualified traffic professionals and the duties they already hold. Remote control of signal behaviour is not part of this monitoring layer; if it is ever appropriate, it is a separate authorised exercise with its own safeguards — see the control boundary on the overview.
Keep exploring
Temporary traffic light questions
What data can a portable signal set actually provide?
It depends on the unit and the interface its owner approves. During discovery we confirm the supported interface and verify what it really emits — which may cover power, comms health and device fault flags, or may be narrower. The design is built on that verified evidence, not on a specification sheet.
Does this replace our traffic management plan checks?
No. The layer references the approved plan prepared by qualified traffic professionals and records field check-ins against it. It does not prepare, approve or modify plans, and it does not replace site supervision or any duty around live traffic.
What happens when a unit loses communications?
Silence becomes its own alert. The last known state stays visible but is clearly labelled offline with the silence duration, and the escalation clock starts. Where the equipment supports buffering, readings caught during the outage are back-filled when contact returns.
Can the system change what the lights do?
Not as part of monitoring. Read-only visibility is the default and, for many fleets, the right permanent answer. Any command capability would require explicit owner authority, equipment support, role controls, confirmation steps, logging, tested safeguards and fallback — a separate exercise from this one.
How do we start?
With a scoped discovery on a handful of units: inventory, ownership, interface confirmation and a data reality check, followed by bench, field and response exercises. You get written findings that are useful whether or not you expand — request a pilot via the quote link below.
Give the fleet a voice before the public gives you the news
Start with one depot's sets and one job type. We will scope the discovery stage around your units and your call-out reality.