Embedded Systems
Intelligence Beyond the Cloud.
Not every decision can wait for a round trip. We build the software that runs on the device — sensing, deciding and acting inside its own power, memory and timing budget, and reconciling with the rest of the system when the network allows.
The Problem
The network is an assumption the physical world does not honour.
Not every decision can wait for a round trip. We build the software that runs on the device — sensing, deciding and acting inside its own power, memory and timing budget, and reconciling with the rest of the system when the network allows.
Connected products are often designed as thin clients: the device samples, the cloud decides, the device acts. It works in the lab. In a plant, a vehicle, a field or a basement, connectivity is intermittent, latency is variable, and bandwidth costs money per device per month, forever.
The second constraint is harder. The device has a fixed budget for power, memory and time; it has to hold real-time guarantees; and it will run essentially the same firmware for years, updated over links nobody supervises, on hardware nobody will physically touch again.
So the real question is placement — which decisions belong on the device, which at a gateway, which centrally — and it has to be answered before the hardware is fixed, because it determines the silicon, the power architecture and the bill of materials.
Our Approach
How we work on this.
The same order every time. Understanding before design, design before build, evidence before scale.
- 01
Fix the constraint envelope first
Power, memory, duty cycle, thermal headroom, timing determinism, certification and unit cost. Every later decision is a trade inside that envelope, so we write it down before anyone designs against it.
- 02
Place the intelligence deliberately
Which inference runs on-device, which at the gateway, which in the cloud. We push each decision as close to the sensor as the budget allows and no closer, then justify the boundary in both directions.
- 03
Build the sensing path honestly
Calibration, drift, noise and failure modes are engineered explicitly, in the acquisition path. Analytics built on unvalidated sensor data is confident nonsense, and it is confident all the way to the dashboard.
- 04
Make deployment safe from the first build
Signed, resumable, A/B over-the-air updates with rollback, plus provisioning and key revocation — designed in, not retrofitted after the first fleet-wide incident.
- 05
Instrument the fleet
Health, telemetry and diagnostics sized to the bandwidth budget, so field behaviour informs the next firmware release rather than the next warranty claim.
Capabilities
What this covers.
Named plainly, so you can tell whether we are the right people for the piece of work you have.
- Embedded Software
- Firmware
- IoT
- Edge Computing
- Sensor Integration
- Device Intelligence
- Hardware/Software Integration
- Real-Time Systems
Technical Architecture
The shape of the work.
- 01
Sense
Calibrated sensors sampled at a rate the power budget allows, with drift and fault detection inside the acquisition path rather than downstream of it.
- 02
Decide on device
Filtering, classification or inference within the timing budget, so control loops close locally and keep holding when connectivity does not.
- 03
Act
Deterministic actuation, with safe states defined explicitly for degraded input, lost connectivity and low power.
- 04
Sync
Store-and-forward telemetry sized to the bandwidth actually available, reconciling state when the network returns rather than assuming it never left.
- 05
Improve
Fleet data trains the next model; signed over-the-air updates roll it out in stages, with rollback exercised before it is needed.
Use Cases
Where this applies.
If one of these reads like a description of your week, it is the right conversation to start with.
Industrial equipment that must keep deciding offline
Control and anomaly detection that hold their guarantees when the uplink drops, and reconcile cleanly when it comes back rather than replaying a day of stale commands.
Condition monitoring retrofitted to existing assets
Sensor packs and gateways added to machinery that predates connectivity, without touching the certified control system or invalidating its approval.
On-device inference under a power budget
Quantised models sized for a microcontroller, where streaming raw signal to the cloud would cost more in radio and subscription than the compute ever costs on the device.
A fleet you can actually update
Signed, resumable over-the-air delivery with staged rollout and rollback, for devices you will never physically reach again.
Hardware and software bring-up in parallel
Board support, drivers and integration rigs developed alongside the hardware, so first silicon is not also first integration.
Real-time control with a maintainable stack
Deterministic timing on the critical path, and something a normal team can maintain on everything that is not.
Business Impact
What changes.
Stated as outcomes rather than percentages. We publish numbers for work we measured, on the page for that work.
Devices keep working through connectivity loss instead of degrading to useless.
Bandwidth and cloud cost per device fall, because the device sends conclusions rather than raw signal.
Field updates become routine and reversible, so a defect is a deployment rather than a recall.
Failures are seen before they are felt, because health telemetry was designed in rather than inferred later.
Product life extends, because new capability arrives by firmware instead of by new hardware.
Hardware and software schedules stop blocking each other at the integration milestone.
Related Work
Worked examples.
Realistic problems taken through architecture, implementation and the trade-offs we would argue for in a real engagement.
- DemonstrationIndustrial manufacturing
Intelligent Operations Platform
A reference architecture for unifying plant telemetry, work orders and quality records behind one operational data model, with model-assisted triage layered on top.
- DemonstrationProcess industry
Predictive Maintenance System
A demonstration of condition monitoring done end to end: instrumentation and edge processing on constrained hardware, through to a maintenance workflow that acts on a signal rather than a dashboard.
FAQ
Questions we are usually asked.
Embedded systems
Tell us what the device has to decide on its own.
A constraint envelope, a sensing path, on-device intelligence, or a fleet you cannot safely update. Bring the part that has to work without a network.