IoT & Traffic Systems · Fixed assets · Messaging
Permanent VMS signage with governed messages and health evidence.
GA Applications designs integrations for permanent VMS signage that keep four states distinct — what was requested, what was sent, what the sign acknowledged, and what was actually observed — alongside display, network and power health. Message governance stays with the owning authority; the digital layer makes it visible and auditable.
For road authorities, motorway operators and their contractors, where a gantry sign is public infrastructure: every message needs a chain of custody, and every fault needs an ending.
Templates, routine approval, and the emergency path
Permanent signs run on governance. The design supports three lanes, all configured with the owning authority:
- Template library — pre-approved message structures with rules for when each applies. Content is supplied and owned by the authority; the library enforces consistency, it does not write copy.
- Routine approval — named approver roles, recorded decisions, scheduled releases. The record shows who approved what, against which template, and when.
- Emergency path — a documented, rehearsed route for urgent messages: fewer steps, named senior roles, mandatory after-action review. Faster, but never anonymous — the audit trail is what makes speed defensible.
What the software never does is decide public message content on its own. Where any AI assistance is used — for example drafting a routine variant from an approved template — it shows its source, carries uncertainty, and waits for human approval like everything else.
Requested ≠ sent ≠ acknowledged ≠ observed
- Requested — an authorised person asked for a message. Intent, recorded.
- Sent — the platform dispatched it to the sign. An action, timestamped.
- Acknowledged — the sign confirmed receipt via its approved interface. Equipment's own report.
- Observed — a person or verified mechanism confirmed what the sign actually displays. The only state the public experiences.
Collapsing these into one green tick is how wrong signs stay wrong. Here, a gap between any two states is itself a reportable event.
Display, network and power health as first-class citizens
Message governance tells you what should be on the sign; health evidence tells you whether the sign is in a condition to show it. The three families are monitored separately because they fail separately, route to different responders, and are restored on different clocks.
Sign face health
What the sign's approved interface reports about its display function — faults, degraded elements where the equipment supports that detail — with source and time on every value.
Path health
The communications path between platform and sign is monitored as its own asset. A silent path means unknown sign state, and the dashboard says exactly that.
Supply and backup
Supply status and backup-power readiness where interfaces expose them, including maintenance facts like overdue tests — the warnings that precede the outage.
Detect, assess, assign, repair, restore
Faults follow a five-step lifecycle with evidence at every step. Detection comes from health monitoring or field report; assessment classifies likely cause and priority in context; assignment names a responder with the sign's history attached; repair is documented with checks and photos; restoration is confirmed against the data and, where warranted, a field observation — then reviewed before closure.
Electrical and structural work stays with qualified contractors. The digital layer coordinates, records and verifies — it does not certify anything.
| Term | Definition |
|---|---|
| Availability | The proportion of an agreed period in which a sign met its defined normal state — calculated from source-stamped records, with the period and exclusions stated beside the figure. |
| Response | Time from detection to acknowledgement, and from assignment to arrival — reported as measured distributions, never as guarantees. |
| Repeat fault | The same fault class on the same asset within an agreed window — flagged for root-cause review rather than another identical repair. |
Where the boundaries sit
Message authority, content standards, network operations and statutory duties remain with the owning road authority and its qualified contractors. GA Applications designs the integration, governance workflow and evidence layer. Any direct message-release capability beyond the authority's existing systems would be a separately authorised exercise — with identity verification, confirmation steps, logging, tested safeguards and fallback — not a feature of monitoring.
Keep exploring
Permanent VMS questions
Who controls what a permanent sign says?
The owning road authority, under its own content standards and approval structures. The digital layer implements that governance — templates, named approvers, recorded decisions, a rehearsed emergency path — and makes it auditable. It never originates public message content.
Why keep requested, sent, acknowledged and observed separate?
Because they fail separately. A message can be requested but never sent, sent but not acknowledged, or acknowledged while the sign face shows something else. Only an observation confirms what the public sees, so each state is stored as its own fact with its own time, and any gap between them is a reportable event.
How are urgent messages handled differently?
Through a documented emergency path agreed with the authority: fewer steps, named senior roles, and a mandatory after-action review. The audit trail is deliberately preserved — speed without attribution is not a feature, it is a liability.
What do availability figures on these dashboards actually mean?
Exactly what their definition says: the proportion of a stated period in which a sign met its defined normal state, calculated from source-stamped records, with exclusions such as declared maintenance windows shown beside the figure. No definition, no number.
Can this integrate with our existing traffic systems?
That is determined by interface discovery with the asset owner: which approved interfaces exist, what they provide, and under what conditions. The integration is designed to those confirmed interfaces — read-only first — rather than assuming any particular vendor or protocol.
Make every message provable and every fault finite
Start with a handful of signs and the governance you already run. We will scope the interface discovery and show what an auditable chain looks like on your corridor.