IoT & Traffic Systems · Capability · Data layer
IoT equipment monitoring that knows what it knows — and what it doesn't.
GA Applications designs the monitoring layer beneath the dashboards: a registry of devices and their approved interfaces, gateways that collect and buffer, validation checks that grade every reading, and alerts that arrive with context and an owner. The output is an evidence trail from event to review — not a wall of uncriticised telemetry.
For operators who already have connected equipment but not connected understanding: the difference between data and knowledge is validation, context and ownership.
The registry: devices and interfaces, not mystery endpoints
Every monitored thing has a registry entry, and every entry names its approved interface — the confirmed, documented way its data may be collected, established with the equipment owner during discovery. The registry records what each interface genuinely provides, how often, and what it does not provide. That last column matters: it stops dashboards implying knowledge the equipment cannot supply.
When equipment is replaced, re-firmwared or re-deployed, the registry is where that change lands — so history stays attached to the asset while configuration stays honest about the present.
Inputs, outputs and authoritative sources
Inputs: approved device interfaces, gateway health signals, field check-ins and observer confirmations. Authoritative source for any value: the interface or person named beside it — never the platform itself. Outputs: validated status, owned alerts, evidence-linked work records and the reporting layer the dashboards read. No output is more authoritative than the input it cites.
Collect, buffer, confess
- Collect — poll or receive on the schedule each interface supports. No invented real-time: intervals are shown, not hidden.
- Buffer — where the equipment supports it, readings queue through outages and back-fill on reconnection, marked with their original timestamps.
- Confess — the gateway's own health is monitored like any other asset. A silent gateway raises its own alert: the data stopped, and the system says so.
“We lost the feed” and “the equipment failed” are different events with different responders. The design refuses to merge them.
Five checks every reading passes — or fails in public
Validation is not a cleanup step; it is the product. Each reading is graded before it can change a status or raise an alert, and failures stay visible with their reason.
| Check | Question it answers | On failure |
|---|---|---|
| Freshness | Is this reading inside its agreed age window? | Marked stale; statuses derived from it are restyled and re-labelled. |
| Range | Is the value physically plausible for this device and field? | Labelled suspect; held out of status derivation; reviewable. |
| Sequence | Did readings arrive in a plausible order, with expected continuity? | Gaps surfaced explicitly — shown as gaps, not interpolated away. |
| Duplicate | Is this the same reading again through a retry or a second path? | De-duplicated with the surviving copy citing both sources. |
| Confidence | Given all of the above, how much weight should this reading carry? | Low-confidence values display their grade beside them, in words. |
Contextual alerts with an owner, not alarm confetti
An alert from this layer carries its context with it: the asset, the site and deployment window, the source reading and its time, the check that fired, and the rule that decided priority. Priority itself is contextual — the same voltage reading means different things in a live window and in the depot, and the rules know the difference because your people wrote them with us.
And every alert lands with a named owner or a named escalation path. An alert nobody owns is deleted at design time, on the grounds that it is noise wearing a uniform.
Event → triage → work → evidence → review
- EVENTA validated signal crosses a rule
Source, time and check result attached at birth. (Illustrative flow.)
- TRIAGEContext decides priority
Deployment window, asset role and recent history shape the ranking — agreed rules, visible to everyone.
- WORKA named person acts
Acknowledgement, assignment and field response, with asset history in hand.
- EVIDENCEThe fix is documented
Checks, photos, parts, restoration confirmation — filed against the asset.
- REVIEWThe loop is audited
Supervisors sample closures; repeat faults and noisy rules feed the next design iteration.
Security and privacy
Read-only-first collection, least-privilege access, logged actions, and retention agreed up front. Equipment data is about equipment; where field evidence could identify people, capture is minimised and correction or removal runs through hello@gaapplications.com.
Failure and offline behaviour
Every component has a declared degraded mode: gateways buffer where supported, stale data is restyled rather than hidden, validation failures are labelled, and platform maintenance windows are declared with owners and end times. The system's honest answer is sometimes “unknown” — by design.
Keep exploring
Equipment monitoring questions
Our equipment is from several manufacturers. Is that a problem?
It is the normal case, and the registry model is built for it. Each device type goes through interface confirmation and a data reality check, so the design reflects what each one genuinely provides. Uniformity is never assumed — differences are modelled, not smoothed over.
Is this “real-time” monitoring?
Only where the confirmed interface actually delivers data in near-real-time — and then the interval is shown beside the value. Many field devices report on slower schedules, and the design displays those honestly instead of implying a live stream that does not exist.
What happens to data during a communications outage?
Where the equipment supports buffering, readings queue at the gateway and back-fill with original timestamps when contact returns. Where it does not, the gap is shown as a gap. Either way, silence raises its own alert and stale data is restyled so it cannot pass as current.
Who decides what deserves an alert?
Your people, with us, at design time. Rules are written in plain language, tested in exercises, and reviewed after real use — noisy rules are tuned or deleted rather than allowed to train your team into ignoring the queue.
Where does this layer sit relative to the dashboards?
Underneath them. Monitoring produces validated status, owned alerts and evidence-linked records; the control-centre dashboards are one reader of that layer. Keeping them separate means a new screen never requires new telemetry, and a telemetry fix improves every screen at once.
Turn scattered telemetry into a defensible record
Start with one device family and one gateway. The discovery stage produces a written interface and data-quality assessment that stands on its own.