IoT & Traffic Systems · Fleet · Messaging
Temporary VMS boards, from message request to confirmed display.
GA Applications designs the workflow and monitoring layer for temporary VMS fleets: who requested a message, who approved it, what was released to which board, what the board confirmed it is showing — and, just as clearly, when nobody actually knows. Message content and approval authority stay with the responsible organisation.
For traffic-management teams and project managers whose boards carry messages the public acts on: “we think it's showing the right thing” is not a status.
ROADWORK AHEAD
MERGE LEFT →
CONFIRMED BY BOARD 08:41:12
Request, approval, release — with names and times
A public message is a small act of authority. The workflow records who requested it (with the job and reason), who approved it (a named approver role, within agreed message rules), and what was released to which board. Content and approval wording come from the responsible organisation — the traffic contractor, authority or project team — never invented by the software.
Every hop is timestamped and attributable, so when someone asks “who put that up and when?”, the answer is a record, not a reconstruction from phone logs.
Asset, job and deployment window
Like any fleet asset, each board carries identity, assignment and a deployment window. A message release is only meaningful in that context: the right message on the wrong board, or outside its window, is an exception — and the system treats it as one.
| State | Meaning |
|---|---|
| Desired | What the approved record says the board should be showing now. |
| Confirmed | The board (via its approved interface) or a field observer has confirmed the actual display matches. |
| Mismatch | Confirmed display differs from desired — an exception with an owner and an escalation clock. |
| Unknown | No confirmation available. Shown plainly; never upgraded to “assumed correct”. |
Requested content is not proof of observed state — the distinction this entire page is built around.
Power, comms and fault health beside every message
A message record without equipment health is half the story. Boards fail the way trailers fail — flat batteries, dead comms modules, device faults — usually at the worst time in the deployment window. Health states ride alongside message states, so an approver can see that the board they are about to release to has been silent for forty minutes.
Supply and charging
Voltage and charge-source readings where the confirmed interface provides them, with agreed floors that raise power-class alerts before the board dies mid-window.
Contact and silence
Last-seen time on every board. Silence is its own event: last known state stays visible, labelled offline, with the duration and an owner.
Device-reported faults
Whatever the approved interface genuinely reports — no more, no less — verified during discovery and mapped to alert classes with named responders.
Repair evidence that outlives the job
When a board is fixed — a panel swap, a battery change, a comms repair — the intervention is documented against the asset: arrival, checks, photos, parts, restoration confirmation, supervisor review. Over a season, that trail separates the reliable boards from the repeat offenders and gives warranty conversations something to stand on.
Field work around live corridors follows the contractor's own safety procedures; the digital layer records and coordinates, it does not direct traffic or replace supervision.
Today, forward plan, exceptions
Three views run the fleet day to day — each a filtered cut of the same records, all with list and table equivalents:
- Today — boards in live windows: message state, health state, open alerts. Built for the morning check and the 2am call.
- Forward plan — upcoming windows and releases: which boards are committed where, which are unconfirmed, where readiness gaps exist.
- Exceptions — only what needs a decision: mismatches, unknowns past their window, unacknowledged alerts, overdue returns. Empty on a good day, and honest about it.
Where the boundaries sit
Message wording, approval authority and any statutory requirements for sign content remain with the responsible organisation. GA Applications designs the workflow, monitoring and evidence layer — it does not author messages, approve traffic arrangements or guarantee what any physical board displays at any moment. Confirmation comes from the equipment's approved interface or a field observer, and the system says “unknown” when it has neither.
Keep exploring
Temporary VMS questions
Who writes and approves the messages?
Your organisation. Message content, templates and approval authority stay with the responsible traffic contractor, authority or project team. The system records who requested and who approved each release, with times — it never authors public message content itself.
If a board says a message was sent, is it definitely showing it?
No — and the design never treats “sent” as proof. A display is “confirmed” only when the board's approved interface reports it or a field observer verifies it. Without either, the state is shown as unknown, and a mismatch between desired and confirmed display raises an exception.
What happens if a board loses power or comms mid-deployment?
Agreed thresholds raise power or comms alerts with a named owner, and the board's last known state stays visible but clearly labelled. Silence itself is an alertable event, so a dead board inside a live window surfaces quickly instead of being discovered by a driver.
Can the system push messages to boards automatically?
Releases follow the approved workflow with named human approval. Deeper automation or direct command integration would be a separate, gated exercise requiring owner authority, equipment support, confirmation steps, logging and tested fallback — never part of monitoring by default.
How does a pilot usually start?
With a small number of boards on real jobs: interface confirmation, a data reality check, then the request-to-confirmation workflow running alongside your current process until the records prove themselves. Scope via the quote link below.
Know what the board shows — or know that you don't
Start with the boards on your busiest corridor. We will scope a pilot around your approval workflow and your fleet's real interfaces.