IoT · edge · connected systems

IoT and edge software

I design systems that connect devices, protocols, Linux edge runtimes, data and applications when local reliability and observability are part of the problem.

Typical problem

Data starts in the physical world, but it must become reliable before it reaches the interface

An edge system is more than reading a sensor. It must handle protocols, disconnections, persistence, data quality, recovery and clear boundaries between what must run locally and what may depend on the network.

Heterogeneous devices and protocols

Meters, relays, gateways and serial or network interfaces need to be translated into a coherent, verifiable software model.

Connectivity is not guaranteed

Critical behaviour should continue locally when cloud services, networks or external dependencies are unavailable.

Operational data needs integrity

Sampling, timestamps, validation, persistence and rebuild paths must prevent faults or restarts from turning telemetry into ambiguous information.

Use cases

When edge belongs in the solution

Architecture is chosen around the actual context: measurement frequency, protocols, autonomy requirements, available hardware and how people or other systems need to consume the data.

Acquisition and normalization

Read measurements or states from devices, validate them and turn them into data that storage, APIs and user interfaces can use.

Local control and automation

Operational logic that needs to stay close to the device rather than depend on an external connection for normal operation.

Telemetry and history

Local persistence, rollups, time series and APIs for analysis, diagnostics and visualization without overloading the hot path.

Edge / service integration

Explicit boundaries between local runtime, backend, dashboards and remote services, with synchronization or supervision only where useful.

Approach

Operational behaviour first, stack second

Design starts from field constraints and defines responsibilities and failure modes before choosing protocols, storage or frameworks.

01
Map signals, devices and failure modes
Define what is measured or controlled, frequencies, protocols, expected quality and behaviour when a device or network disappears.
02
Separate acquisition, state and data consumption
Collectors, persistence, APIs and UI receive distinct responsibilities so they can be tested, replaced and recovered without fragile coupling.
03
Verify in the real operating context
Recovery, restarts, disconnections, persistence and coherence are checked on the actual runtime, not only under ideal conditions.

Possible outputs

A verifiable technical boundary

The deliverable depends on the engagement mode and can cover one focused slice or the complete end-to-end system.

Edge architecture and responsibility boundariesCollector / device driverLocal persistence and data modelAPIs and integration contractsTelemetry and dashboardsLinux services and deploymentRecovery and diagnosticsTests across the real hardware path

Engineering evidence

Projects that demonstrate these boundaries in practice

The capabilities described here point to documented implementations rather than an abstract technology list.

New connected system

Start with the devices, constraints and what must keep working

In the brief, include existing hardware or protocols, what needs to be measured or controlled and which part of the system must not depend on external connectivity.

Send an IoT / edge brief