Services · IoT & Traffic Systems

Connect temporary and permanent road equipment to one visible operating system.

GA Applications designs the digital layer around temporary traffic lights, permanent traffic signal integrations, temporary and permanent VMS boards, field sensors and related equipment. The work can connect equipment identity, approved status data, alerts, maintenance records, site checks, authorised actions and dashboards while keeping traffic-control and engineering decisions with the responsible specialists.

For traffic-management and civil businesses, equipment coordinators, maintainers, field supervisors, asset owners and control-centre teams who need to know what is deployed, where, in what state, and what happened next — without pretending the data is fresher or more authoritative than it really is.

Plan an IoT traffic pilot Send a direct enquiry

Interface demonstration — illustrative data A representative estate view: six asset types, each shown with a state and a freshness time. Stale and offline assets are deliberately styled so they cannot be mistaken for healthy ones. An accessible list of the same demonstration data follows in the asset registry section.

Who this is for — and when it is the wrong tool

The business problem is rarely a lack of equipment. It is that identity, deployment context, status, alerts and maintenance history live in different places — a spreadsheet, a group chat, a supplier portal, a whiteboard — so nobody can answer a simple question with confidence: what is out there right now, and is it working?

A good fit when

You operate or coordinate temporary traffic lights, VMS boards, signal sites or field sensors across multiple jobs.
Alerts already exist somewhere but arrive without context, ownership or a closure trail.
Maintainers need service history and field evidence attached to the asset, not to someone's memory.
Managers want a portfolio view built from the same records the field teams use.
You are prepared to start with a limited, read-only monitoring pilot and expand on evidence.

Not the right tool when

You need a traffic management plan prepared or approved — that stays with qualified traffic professionals.
You need equipment manufactured, supplied, installed or electrically certified — GA Applications designs the digital layer, not the hardware.
You want remote control of signals or signs switched on immediately — command capability is a separate, gated design exercise, never automatic.
You expect guaranteed uptime, response times or savings — no performance figures are promised without a measured pilot.

One asset registry: every item knows its job, site, state and history

The foundation is a registry where each physical item — controller, signal set, sign, trailer, gateway, cabinet or sensor — is a first-class record linked to its deployment and service history. Dashboards, alerts and reports all read from this single spine, so a manager's view and a maintainer's work order describe the same object.

What an asset record can hold (demonstration structure)
Field group	Example contents	Why it matters
Identity	Asset ID, type, serial, firmware, accessories	Stops “which unit is that?” debates during an incident.
Deployment context	Job, site, position, deployment window, approved-plan reference	Status is meaningless without knowing where the asset should be and for how long.
State & freshness	Connected / degraded / offline / stale, source, last-seen time	Every reading carries its age and origin, so old data never poses as current.
Alerts	Open alerts, owner, acknowledgement, escalation state	An alert without an owner is just noise.
Service history	Faults, field checks, photos, repairs, restoration evidence	Repeat faults become visible; warranty and handover conversations get evidence.

Demonstration data — illustrative

The same estate, as a list

Every map and visualisation in this subsite ships with an equivalent list or table, because a map is a convenience, not an accessibility shortcut.

Connected TTL set A-14 · last seen 42s ago
Degraded VMS trailer T-03 · supply voltage low
Normal Signal site S-221 · source 08:41:12
Stale Permanent VMS V-108 · last update 07:58
Offline Gateway G-07 · silent 26 min
Connected Sensor array K-2 · last seen 12s ago

Six equipment and capability routes

Each route has its own operating reality — a trailer fleet on shifting roadworks is not a fixed signal cabinet, and a temporary message board is not a permanent motorway sign. Follow the one that matches your estate.

Fleet · Roadworks

Temporary traffic lights

Assignment and deployment windows, controller and accessory readiness, connected/degraded/offline status, power and comms alerts, and field intervention evidence.

Explore route → Fixed assets · Interfaces

Permanent traffic signals

Site, cabinet and controller topology, normal/warning/fault/stale definitions, source-stamped status and a read-only-first cyber model agreed with the asset owner.

Explore route → Fleet · Messaging

Temporary VMS boards

Message request, approval and release; desired vs confirmed vs unknown display state; power and comms health; today, forward-plan and exception dashboards.

Explore route → Fixed assets · Messaging

Permanent VMS signage

Governed templates, routine and emergency approval paths, requested/sent/acknowledged/observed states, and display, network and power health evidence.

Explore route → Capability · Data layer

IoT equipment monitoring

Device and interface registry, gateway collection with buffering, freshness and quality checks, and contextual alerts with an evidence trail.

Explore route → Capability · Visibility

Control-centre dashboards

Operator, coordinator, maintainer and manager views; exceptions before decoration; stale-data prominence; command preview only where approved.

Explore route →

The operating loop: sense, validate, prioritise, notify, resolve

Every page in this subsite is a variation on one disciplined loop — deliberately boring, because boring loops are the ones people follow at 2am.

Sense
Collect approved status data from equipment, gateways and field check-ins — only through owner-confirmed interfaces.
Validate
Check freshness, range, sequence and duplicates. Failures are labelled stale or suspect, never silently trusted.
Prioritise
Score by context — a dead board on a live lane closure outranks the same fault in the depot. Rules are agreed with the operator.
Notify
Route to a named role with evidence attached — asset, site, state, source time — not a bare alarm.
Resolve
Acknowledge, assign, act, attach evidence, close. The loop feeds service history and portfolio learning.

Visibility, recommendation and control are three different things

Most trust failures in operational software come from blurring these layers. The design keeps them visibly separate; moving between them is an explicit, documented decision with the equipment owner.

Layer 1 · Default

Visibility

Read-only monitoring through owner-approved interfaces. The system shows state, freshness and evidence; it changes nothing in the field. Every pilot starts here — many should stay here.

Layer 2 · Optional

Recommendation

The system drafts prioritised suggestions with sources and confidence shown. A person decides; nothing is actioned automatically.

Layer 3 · Gated

Authorised control

Only where equipment supports it and the owner grants it in writing: named roles, action confirmation, full logging, tested safeguards, defined fallback. Never default.

Control boundary, in plain language

A control boundary is the documented line between what the software may show, what it may suggest and what it may do. GA Applications designs the digital layer only. Traffic-control decisions, traffic engineering, electrical work, equipment selection, commissioning and statutory approvals remain with the appropriately qualified people and authorities who hold them today. A suitable, approved interface must be confirmed before any equipment connection is claimed — and a requested command or message is never presented as proof of what equipment actually displayed or did.

Six roles, six honest views of the same truth

Permissions follow responsibility. A viewer should not see command controls; a maintainer should not be asked to approve public messages. Each role below sees the same underlying records through a different, deliberate lens. (Demonstration views — switch between them; nothing here connects to real equipment.)

Viewer

Read-only estate status for stakeholders who need assurance without operational access. No acknowledgement, no editing, no control affordances.

ReadNo acknowledgeNo editNo commands

Operator

Watches the live queue: acknowledges alerts, adds situation notes, escalates to a coordinator. Sees full status detail and source timing; triggers no equipment action.

ReadAcknowledgeAnnotateNo commands

Coordinator

Owns deployment context: assigns assets to jobs and windows, triages escalations, dispatches maintainers, confirms returns to service. Works from the forward plan and exception views.

ReadAssign & dispatchEdit deploymentNo commands

Maintainer

Receives work with asset history attached — past faults, parts notes, photos. Records field checks, repairs and restoration evidence: the entry point of the service-history trail.

Read assignedRecord workAttach evidenceNo commands

Supervisor / message approver

Approves VMS message releases within agreed templates, reviews evidence quality, signs off safety-relevant closures. Where authorised control exists at all, this role is part of its confirmation chain.

ReadApprove messagesSign off closuresControl only where separately authorised

Manager

Sees portfolio patterns, not individual alarms: readiness by fleet, alert-ownership health, repeat-fault leaders, evidence completeness. Built for weekly review, not for watching dots on a map.

ReadPortfolio trendsNo operational actions

Supported-interface discovery, read-only first

Nothing is connected on assumption. Each asset type goes through documented discovery: which interfaces the owner actually approves, what data they genuinely provide, how often, and under what conditions.

Inventory and ownership. List the equipment, its owner, and who may authorise an interface. If that is unclear, the item stays unconnected.
Interface confirmation. Confirm the documented interface for each asset type with the owner or supplier — not a workaround.
Data reality check. Capture what the interface really emits: fields, timing, gaps, failure modes. Design to the evidence, not the brochure.
Read-only first. The first integration only reads. Command capability, if ever appropriate, is a separate gated exercise.

Freshness is displayed, not assumed

A status without a timestamp is a liability. Every reading carries source and age, and the system says plainly when it does not know.

Connected — data flowing within its expected interval; last-seen time shown beside it.
Degraded — data flowing, but something is wrong: low voltage, weak signal, a device fault flag.
Stale — older than its agreed freshness window; styled so it can never pass as current.
Offline — communication has stopped; last known state stays visible, labelled, with the silence duration.
Unknown — no reliable basis for a claim; the system says so rather than guessing.

Communication loss is itself an event with an owner — “equipment reported a fault” and “we have stopped hearing from the equipment” are different situations, and the design never merges them into one red dot.

Alerts with an owner, an acknowledgement and an ending

An alert is a small contract: someone named sees it, takes it, acts, and closes it with evidence. The queue below demonstrates that lifecycle — acknowledge an alert to see the state change. It is page-local: nothing is sent anywhere, no equipment or person is contacted.

Demonstration alert queue — illustrative data only
Alert	Asset · site	Source time	Owner	State	Demo action
Supply voltage low Rule: power class, live deployment window	VMS trailer T-03 · Job 1187 northbound taper	08:36:41 (12 min ago)	Unassigned	Raised
Gateway silent 26 min Rule: comms loss beyond 2× interval	Gateway G-07 · Depot yard west	08:22:05 (26 min ago)	Unassigned	Raised
Display mismatch cleared Requested vs observed state realigned	Permanent VMS V-108 · Eastern corridor	07:58:52 (field-observed)	R. Demo (maintainer)	Closed with evidence	Photo + restoration note attached

Escalation is time-based and visible: an acknowledged alert with no owner inside the agreed window steps up to the coordinator, and a safety-relevant closure without evidence reopens. Every transition is logged with who, when and why.

Field checks, photos, maintenance and restoration evidence

Field work closes the loop telemetry opens. A maintainer's visit is structured evidence — arrival, checks, photos, parts, restoration confirmation — attached to the asset record, not stranded in a text message. It proves the response to the people running the job, builds the service history that exposes repeat faults, and gives supervisors something reviewable at sign-off.

Field workflows support coordination and record-keeping; they never replace emergency procedures, competent supervision or the legal duties that apply on a live road corridor.

08:41 · ASSIGNEDWork order dispatched
Coordinator assigns T-03 voltage alert to nearest qualified maintainer, with asset history attached. (Illustrative scenario.)
09:15 · ON SITEArrival recorded
Maintainer checks in against the job and asset; the record notes who is attending and when.
09:38 · EVIDENCEChecks and photos attached
Battery and charging inspection documented with photos; failed component identified and logged.
10:05 · RESTOREDRestoration confirmed
Replacement fitted; status returns to connected and the closure awaits supervisor sign-off — not automatic.

A realistic pilot path: discover, design, integrate, exercise, expand

No fixed prices or delivery times are promised — scope follows your equipment, interfaces and operating model. What is fixed is the shape of the engagement and the acceptance checks that decide whether it worked.

Discover
Inventory, ownership, interface confirmation and a data reality check for one asset class. Acceptance: a written assessment useful even if we stop here.
Design
Registry model, state definitions, alert rules, role map and wireframes agreed with your team. Acceptance: signed-off definitions.
Integrate
Read-only connection to a small number of agreed assets. Acceptance: source-stamped data verified against field observation.
Exercise
Bench, field and response exercises with your people. Acceptance: your team runs the loop without us in the room.
Expand
Extend asset classes and roles; deeper integration only where separately authorised. Acceptance: each step gated on the last one's evidence.

What success looks like when it is working

The operating outcomes the system is designed around — reviewed together during and after a pilot, never promised as guaranteed metrics.

Readiness

Equipment readiness

Before a window opens, the coordinator sees which units are ready and which carry unresolved faults — from records, not phone calls.

Ownership

Response ownership

Every open alert has a named owner, an acknowledgement time and an escalation path.

Evidence

Maintenance evidence

Repairs carry photos, notes and sign-off — a service history that survives staff turnover and supports warranty conversations.

Learning

Portfolio learning

Repeat-fault patterns and alert-rule noise become visible at fleet level, informing each season's buying and maintenance decisions.

Plain-language definitions

The words on these pages mean specific things. If your organisation uses different terms, the design adopts yours — what matters is one shared vocabulary.

VMS (variable message sign): A road sign whose message can change — from trailer boards at roadworks to permanent gantries. “Display state” means what it is actually showing, known only when the equipment or a field observer confirms it.
Gateway: A device that collects data from local equipment and forwards it, buffering through outages where supported. A silent gateway means data stopped flowing — not necessarily that equipment failed.
Stale status: Data older than its agreed freshness window, kept visible but clearly marked — an old “all good” is not evidence of a current good state.
Alert acknowledgement: A named person recording “I have seen this and I own the next step.” It stops repeat notifications and starts the escalation clock; it is not resolution.
Control boundary: The documented line between what software may display, recommend and command. Crossing it requires explicit authority, supported equipment, role controls, confirmation, logging, tested safeguards and fallback.

Privacy, security, accessibility and human review

Privacy by scope

Equipment data is about equipment. Where field evidence could identify people, capture is minimised, access is role-based, retention is agreed up front, and correction or removal runs via hello@gaapplications.com.

Security by architecture

Read-only-first integration, least-privilege roles, logged actions, segmented connectivity. Any future command path gets its own threat review and fail-safe design before it is built.

Accessibility as standard

Built to WCAG 2.2 AA intent: keyboard-complete, high contrast, state by more than colour, and every map or chart paired with a list or table equivalent — as this site itself demonstrates.

Human review where it matters

Prioritisation rules, message approvals and any AI-assisted suggestions (via the Chinkara Maven layer, where used) show sources and uncertainty and wait for human confirmation. Professional judgement stays with people.

Questions buyers actually ask

Does GA Applications supply or install the traffic equipment itself?

No. GA Applications designs the digital, software and integration layer around your equipment — the registry, monitoring, alerts, evidence trail and dashboards. Equipment manufacture, supply, installation, electrical work and certification stay with the qualified suppliers and trades you already use.

Can you connect to our existing lights and signs?

Possibly, but only after supported-interface discovery: for each asset type, the approved interface must be confirmed with the equipment owner or supplier, and the data it genuinely provides must be verified. No connection is claimed before that evidence exists, and the first integration is always read-only.

Does monitoring include remote control of signals or signs?

No — monitoring never automatically includes control. Command capability is a separate, gated design exercise requiring explicit owner authority, equipment that supports it, role-based permissions, target and action confirmation, full logging, tested safeguards and a defined fallback. Many deployments rightly remain visibility-only.

What happens when communications drop in the field?

Gateways buffer readings so data is delayed rather than lost where the equipment supports it. The platform treats silence as its own event: the last known state stays visible but is clearly labelled stale or offline with the silence duration, and an alert is raised — old data is never presented as current.

How big should a first pilot be?

Small enough to be honest: one asset class, a handful of units, read-only monitoring, and named people running the alert-to-evidence loop. The discover and design stages produce written assessments and definitions that are useful even if you decide not to expand.

Is the telemetry on this website real?

No. Every map, dashboard view, alert and timestamp in this subsite is an interface demonstration using bundled illustrative data, and each is labelled as such. They show how the system would behave; they are not evidence of a live deployment or a client engagement.

Start with a pilot you can verify

Tell us what equipment you run, who owns it and what you wish you could see. We will come back with a scoped discovery-and-design stage — the same diagnose, scope, research, prototype, build, test, launch and improve language we use everywhere — and no claims we cannot support.