IoT System Architecture for Connected Fleets

Radios, cloud and release engineering for devices that ship in the hundreds and update in the field.

Start a technical conversationAll capabilities

Context

One device on a bench is a demo. Four hundred of them in the field, each reporting every fifteen seconds, is a system, and IoT system architecture is the work of making the second one behave like the first. The hard parts are the ones that rarely make it into the original budget. What happens when a firmware update has to reach three microcontrollers on one board over a cellular link. How a device behaves after a day with no network. Who is allowed to sign an image. How a release reaches production without taking the fleet down to find out. The work here covers that whole path, from the radio and the antenna up through the cloud backend and the pipeline that promotes a build. The low-level software underneath it is covered on Firmware and Embedded Linux.

Scope

What this covers

  • 01IoT system architecture end to end, from the sensor through the radio to the backend.
  • 02Cellular LTE-M and NB-IoT on the Nordic nRF9160 under Zephyr, including AT-command bring-up and link diagnostics.
  • 03LoRa, BLE and NFC on nRF51, nRF52 and nRF52840 under FreeRTOS with SoftDevice.
  • 04433 MHz sub-GHz links, Modbus RTU over RS-485, and CoAP over Wi-SUN.
  • 05MQTT over TLS into AWS IoT Core, with device telemetry backends on AWS.
  • 06On-chip GNSS with assisted GPS to cut time to first fix.
  • 07Fleet over-the-air firmware update orchestrated through AWS IoT Jobs, including cascading multi-MCU update chains: a custom bootloader protocol, SD-card staged self-reflash, and I2C handoff to downstream microcontrollers on the same board.
  • 08Signed and recoverable update paths, so an image is authenticated before it runs and a failed write leaves the device in a state it can come back from.
  • 09Backend architecture behind a fleet: AWS RDS, Timestream, SQS, SNS, API Gateway and messaging integration, sized against the ingestion rate rather than the device count.
  • 10Ingestion pipeline redesign when per-datapoint processing starts reading across multiple tables and databases, so ingestion stays inside its window as the fleet grows.
  • 11Operational dashboards over fleet data, including geospatial analysis and visualization in Python with GeoPandas.
  • 12CI/CD and release engineering that keeps a fleet shippable: GitHub Actions, self-hosted runners, and three-tier promotion across dev, staging and production.

Record

Work behind this

Delivered work, stated as facts rather than claims. Programs and employers are named where naming them is what makes the record checkable. Clients are not.

R-01IoT system architecture running in production across 400+ field devices and 20+ deployments, each device reporting on a 15 second interval.
R-02A single over-the-air job that reached all three microcontrollers on one board over a cellular link, using a custom bootloader protocol with SD-card staged self-reflash and I2C handoff downstream.
R-03A three-tier promotion pipeline running a roughly biweekly release cadence, with select clients validating in staging before a build reached production.
R-04A backend re-architected several times while it kept serving 20+ clients, with production cutovers scoped so only the function being updated went briefly unavailable.
R-05An ingestion pipeline redesigned with data scientists setting the requirements and data engineers doing the build, so per-datapoint processing stayed within its window as device count grew.
R-06Third-party wind sensors brought into an existing telemetry stream over Modbus RTU on RS-485, with the firmware-side polling and register decoding written in house.
R-07A multi-protocol IoT gateway built on embedded Linux and delivered 30 percent ahead of schedule.

Questions

Questions technical buyers ask

Can you take over an existing fleet, or is this only for new builds?

Both, and taking over an existing fleet is the more common request. The first questions are always the same: how a device is updated today, whether an update can be rolled back, how images are signed, and what the device does when the network is unavailable. Those four answers usually determine how much work the handover actually is.

Do you cover the cloud side, or only the device?

Both sides, because the interesting failures live between them. Device telemetry backends on AWS, MQTT over TLS into AWS IoT Core, and over-the-air campaigns orchestrated through AWS IoT Jobs are part of the same design as the firmware that answers them. It is reasonable to scope an engagement to the device side alone when a cloud team already owns the backend.

What does a first engagement usually look like?

An architecture and readiness review of the fleet as it stands: update path, security posture, connectivity behavior, and the release process. The deliverable is a written assessment with a ranked set of risks. From there the work is normally either a specific subsystem, such as building the over-the-air update path, or ongoing engineering alongside the existing team.

Other engineering capabilities

Hardware and PCB DesignRadio ComplianceFirmware and Embedded LinuxLow Power and SolarRobotics and ControlRF and SatelliteNetwork and SecurityInfrastructure and PlatformAgentic AI Systems

Start a technical conversation

Describe the system, the constraint and the deadline. An engineer answers.

Start a technical conversationAll capabilities

Tools and platforms we work with: Nordic nRF9160 with Zephyr. nRF51, nRF52 and nRF52840 with FreeRTOS and SoftDevice. LoRa, BLE, NFC, 433 MHz, Modbus RTU over RS-485, CoAP over Wi-SUN. AWS IoT Core, AWS IoT Jobs, MQTT over TLS. AWS RDS, Timestream, SQS, SNS and API Gateway. Python with pandas and GeoPandas. GitHub Actions with self-hosted runners.