Automation · Sensors & IoT
Sensors and IoT, designed from the decision backwards.
GA Applications designs the software layer for sensor and IoT systems: the measurement requirement, validation, device inventory and health monitoring, and the dashboards and alerts readings feed. Design starts from the decision a measurement must support — not from hardware — and pilots run bench, field, then scale.
Where every sensor project should start
Begin with the decision, not the device
The most common IoT failure is a box of sensors looking for a purpose. We run the design in reverse: name the decision or alert the measurement must support, define the measurement requirement to support it, and only then consider what sensing could deliver it. If no decision changes because of a reading, the sensor is decoration.
The measurement requirement, written down
Before any hardware conversation: what quantity, in what units, at what location, how often, with what accuracy, and what happens when it is unavailable? That requirement is what your qualified equipment providers select and install against — and it is what our software validates every incoming reading against.
Right fit
- You know the decision or alert you need, but not how to instrument it
- Existing sensors produce data nobody trusts or uses
- You need device health and inventory managed, not just readings collected
- A pilot-first approach suits your risk appetite
Wrong fit
- You want us to supply, install or certify hardware — that stays with qualified providers
- The goal is “collect everything and see”
- You need guaranteed readings in safety-critical control loops — we design visibility layers, and safety logic stays with qualified specialists
How the system is structured
Edge, network and application — designed separately, on purpose
Edge layer: sensing with identity
Every device has an identity, a configuration and a health state. Readings carry unit and timestamp from the moment they are created. Where power or connectivity is unreliable, the edge buffers rather than loses — a design decision made per site, not assumed.
Network layer: transport matched to reality
Coverage, bandwidth and power budgets differ between a shop ceiling and a rural fence line. Transport is chosen per deployment with your connectivity providers, and store-and-forward behaviour is specified for the gaps: when the link drops, readings queue and replay in order, and the application marks the gap honestly.
Application layer: where readings become decisions
Validation, storage, presentation and alerting live here — alongside the unglamorous essentials that determine whether the system survives year two: a device inventory, health monitoring (battery, signal, last contact), and configuration management under least-privilege credentials. Devices get the minimum access they need; a compromised sensor should never be a master key.
Proof before scale
Bench, field, then scale
1 · Bench
A small number of devices runs against the full software stack with demonstration data. Acceptance: readings validate, states display correctly, failure behaviour works.
2 · Field pilot
A limited deployment at one site through a real operating period — weather, weekends, the lot. Acceptance: data quality holds, gaps are handled as designed, and the decision the system exists to support actually gets made better.
3 · Scale
Rollout with inventory, health monitoring and a review rhythm. Acceptance: your team can onboard a new device, read its health and retire it without us.
Sensor projects feed naturally into monitoring and alerts and environmental monitoring, and connect to operational dashboards. For traffic-specific sensing, see the dedicated IoT & traffic systems branch.
System contract
Inputs, outputs and interfaces
| Kind | Examples | Authority / owner |
|---|---|---|
| Inputs | Device readings with identity, unit and timestamp; device health (battery, signal, last contact) | Devices are authoritative for readings; validation flags quality rather than inventing certainty |
| Outputs | Validated data store, dashboards and alerts, device inventory and health views, gap reports | Your team owns the decisions the data supports; we own the integrity of the path |
| Interfaces | Device transports and gateways, connectivity providers, downstream dashboards and records | Least-privilege credentials per device; transport chosen per site reality |
Delivery sequence: decision and measurement requirement → bench prototype → one-site field pilot through a real operating period → scaled rollout with inventory, health monitoring and a review rhythm. Our process
Questions buyers actually ask
Frequently asked questions
Do you supply or install the sensors?
No. We design the software and data layer: measurement requirements, validation, device inventory, health monitoring, dashboards and alerts. Device selection, supply, installation and any electrical work sit with your qualified providers, selected against the measurement requirement we write with you.
Which sensor brands or protocols do you support?
We design to the interfaces each deployment actually offers rather than claiming universal support. During scoping we confirm what your chosen or existing devices expose — the readings, units, health data and configuration options — and build the integration to that. Anything uncertain is tested on the bench before it is promised.
What happens when a sensor dies or goes offline?
The system treats lost contact as an event: the device shows offline with its last reading and timestamp, a lost-contact alert follows the severity rules, and buffered readings replay in order when it reconnects. The device inventory tracks battery, signal and last contact so failures are usually visible before they happen.
How accurate will the readings be?
Accuracy is a property of the sensor hardware and its placement — owned by your equipment providers — plus correct handling in software. Our part is to state the measurement requirement, validate incoming readings against plausible ranges, flag quality issues and never present a number as better than its source.
Can we start small?
That is the recommended path. A bench prototype, then a one-site field pilot through a real operating period, then scale — with acceptance checks at each step so you can stop with usable output at any point.
Plan my sensor pilot
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.