Automation · Traffic signals, VMS & barriers
Traffic equipment software that shows the true state, not the hoped-for one.
GA Applications designs the software layer for traffic signals, variable message signs and barriers: device and comms state as actually reported, role-based command authority with logging, approved message libraries, rehearsed degraded modes, and simulation plus witnessed testing before deployment. Traffic engineering and equipment work stay with qualified specialists.
The software pattern, not the vertical
See the true state of signals, signs and barriers
This page explains the general control pattern GA Applications applies to traffic-related equipment: honest state visibility, role-based command authority, approved message libraries, degraded-mode design and witnessed testing. For the complete traffic-equipment operating vertical — deployments, site operations and the full service picture — see the dedicated IoT & traffic systems branch. This page stays deliberately general so the two never compete.
Right fit
- Civil and traffic businesses wanting one truthful state board across devices
- Teams needing command authority separated by role and fully logged
- Operators who want VMS content constrained to an approved library
- Organisations with traffic engineering providers who need a disciplined software layer
Wrong fit
- Anyone seeking traffic engineering, site design or statutory approvals — qualified specialists own those
- Buyers wanting remote control without an authority, logging and fallback model
- Projects expecting us to manufacture, supply or place equipment
The control pattern
Reported state, command authority, degraded mode
Actual device and comms state
The board shows what devices report, with confirmation timing — never what the software last told them to do. A command sent is not a state achieved: the display distinguishes intent, acknowledgement and confirmed state, and a device that stops confirming moves to degraded with its last-known state and timestamp. This single honesty rule prevents the most dangerous failure in remote operations: believing a command worked when nobody checked.
Role-based command authority
Viewers see states and history. Operators send commands — from the approved set, with confirmation — within their authority. Approvers authorise deployment plans and any change to the library. Every command carries identity, time, device acknowledgement and result, and the protocol and cyber boundary with equipment providers is maintained explicitly: which systems may talk to which, over what paths, with what credentials.
Approved message library
VMS content is drawn from a pre-approved library tied to deployment context — not free-typed in the moment. Each message has an identifier, an approver and a context, so what the sign said at any time is a matter of record, not memory.
Degraded mode by design
Comms loss, power events and conflicting commands are rehearsed states, not surprises. Each has a defined degraded behaviour — typically hold last safe state, alert by severity, and revert to on-site manual control per the deployment plan. Nothing about degraded mode is improvised at the roadside.
Simulation and witnessed testing
Before any live deployment, scenarios run in simulation — comms loss, command conflict, recall — and key behaviours are witnessed in testing with your traffic engineering providers. Handover includes the state dictionary, authority matrix, library, degraded-mode plan and test records.
Boundaries and next step
Where this page hands over
GA Applications designs software interfaces, data models, integrations and dashboards for traffic-related systems. Traffic engineering, equipment selection and placement, electrical work, statutory approvals and site safety remain with appropriately qualified parties. For the full operating picture — equipment contexts, deployments and industry-specific journeys — continue to IoT & traffic systems and traffic management, or the civil infrastructure industry page for the wider context.
System contract
Inputs, outputs and interfaces
| Kind | Examples | Authority / owner |
|---|---|---|
| Inputs | Reported device and comms states, command acknowledgements, deployment context | Devices are authoritative for state; intent and confirmed state are shown separately |
| Outputs | State board, role-scoped command paths, library messages, full command log, degraded-mode alerts | Approvers own the plan and library; operators own confirmed commands |
| Interfaces | Equipment controllers and comms paths under an explicit protocol/cyber boundary | Boundary maintained with equipment providers; nothing cross-connects by default |
Delivery sequence: authority model and boundary definition → simulation of failure scenarios → witnessed testing with your traffic engineering providers → handover with state dictionary, authority matrix and degraded-mode plan.
Questions buyers actually ask
Frequently asked questions
Can your software change a signal or sign remotely?
Only within a designed authority model: supported equipment, role-based permission, commands from an approved set, explicit confirmation, device acknowledgement, full logging and a tested degraded-mode fallback. Viewing authority and command authority are separate roles, and every action is attributable. None of this is assumed — it is agreed per project with your qualified providers.
Do you supply or install traffic equipment?
No. Equipment manufacture, supply, placement, electrical work, traffic engineering and statutory approvals remain with appropriately qualified parties. We design the software layer — state visibility, command authority, message libraries, logging and degraded-mode behaviour — alongside them.
What happens if a device loses communication?
It moves to a visibly degraded state showing last-known state and timestamp, an alert follows the severity chain, and operations revert to the documented fallback — typically on-site manual control per the deployment plan. The interface never shows the last command as if it were the current state.
How is VMS content controlled?
Through an approved message library. Operators select from pre-approved messages tied to deployment context; they do not free-type. Each message has an identifier and approver, and what was displayed, when and by whose action is recorded.
How does this page relate to the IoT & traffic branch?
This page covers the general software control pattern that applies to traffic-related equipment. The IoT & traffic systems branch covers the full operating vertical — equipment contexts, deployments and industry journeys. The two are deliberately non-overlapping: pattern here, vertical there.
Discuss traffic software
Tell us about the task, site or signal you want to automate. We will come back with a scoped pilot path — model, test, controlled commissioning, handover.