Sujith Ravikumar · Cloud Engineer, IoT I connect devices to the cloud, and back.

Cloud Engineer at L&T Semiconductor Technologies, working across the whole path a device message takes: device, connectivity, cloud and backend.

See the work Get in touch

Scroll to follow one message Skip the story

  1. Close to the circuit board: the signal runs along a copper trace from the MCU towards the LTE modem.

    01 · Device

    It starts on a board.

    A sensor reading, a GNSS fix, a firmware version: Embedded C on an MCU, on connectivity modules.

    • MCU
    • Embedded C
    • Sensors
    • GNSS

  2. The signal reaching a panel antenna at the top of a cell tower at first light, with a tech park and the city behind it.

    02 · Connectivity

    It crosses the air.

    LTE, Wi-Fi or BLE carries it out. MQTT keeps it light, and TLS keeps it private.

    • LTE
    • Wi-Fi
    • BLE
    • MQTT
    • TLS

  3. A data hall aisle; the signal enters the switch of a rack labelled AWS IoT Core.

    03 · Cloud

    It lands in Cloud infrastructure.

    The cloud application checks the device's identity and routes the message: provisioning, device state, telemetry and OTA updates.

    • AWS IoT Core
    • Provisioning
    • Telemetry
    • OTA / FOTA
    • Lambda
    • S3
    Route a message

  4. A server pulled out of the API rack, its CPU heatsink lit from inside by the signal.

    04 · Backend

    Then it becomes an answer.

    API services, custom business logic, with Databases behind them. A command back to the device taken in the most optimal path.

    • REST
    • GraphQL
    • PostgreSQL
    • Node.js
    • Spring Boot

  5. The device again, its display showing the portrait on firmware 1.5.0 after the update came back.

    One message, four layers.

    Device, connectivity, cloud and backend. I work across all of it.

    See the workGet in touch

Preparing the 3D view

Portrait of Sujith Ravikumar, arms crossed, wearing a navy shirt.
Sujith Ravikumar

About

Where the board meets the backend.

I build cloud and backend systems for connected devices: how a device proves who it is, reports what it sees, takes a command, and updates its own firmware without getting stuck.

My days are architecting cloud solutions, network layer protocols, provisioning and device lifecycle, telemetry, remote AT commands, GNSS/TPS positioning and OTA/FOTA, plus the backend and databases behind them.

I know the device side too: Embedded C, MCUs, A/B partitions, how a module boots. That changes how I design the cloud side.

Now

Cloud Engineer

L&T Semiconductor Technologies

March 2025 to present

India's pioneering fabless semiconductor company, designing semiconductors and smart devices across power, compute, analog, embedded systems and IoT.

Studying

M.Tech, Embedded Systems

BITS Pilani

November 2025 to present

Outcomes

Results, measured.

  • 60%

    faster OTA

    DFOTA

  • 99%

    lower boot failures

    Dual Slot Booting

  • <2 s

    provisioning

    Secure Identity

  • <50 s

    flashing

    SIPS

Selected work

Five systems, one path.

Selected work on AWS IoT Core, MQTT, device provisioning, A/B OTA and identity services, from firmware slots on a module to the identity server behind a fleet. Diagrams are simplified, and every ID, topic and value shown is demo data.

01

Secure Identity and Provisioning Server (SIPS)

Secure Identity and Provisioning Server

Identity for everything a connected product touches: users, organizations, factories, devices and firmware.

  • Cloud
  • Backend
  • Security

<2 sprovisioning

<50 sflashing

Stack Node.js · GraphQL · PostgreSQL · Prisma · Keycloak · OAuth2 · JWT · Docker · AWS

SIPS architecture: clients sign in through Keycloak and call a Node.js GraphQL API with a JWT. The API uses Prisma over PostgreSQL and covers users, factories, firmware releases, product catalog, TAC, IMEI and device provisioning. It runs in Docker on AWS. Docker · AWS Clients KeycloakOAuth2 · JWT GraphQL APINode.js Prisma PostgreSQL sign in JWT verify Users Factories Firmware releases Product catalog TAC IMEI Device provisioning
Fig. 01 · SIPS, simplified

Problem

A connected product needs trusted records for people, factories, devices and firmware, and those records have to agree with each other.

Architecture

Identity and Access Management with OAuth2 and JWT. A Node.js GraphQL API sits behind it, using Prisma over PostgreSQL, in Docker on AWS.

Engineering

Users and organizations, factories, firmware releases, product catalog controls, TAC management, and IMEI and device provisioning.

Result

Provisioning in under 2 seconds and flashing in under 50 seconds, with users, devices and firmware releases managed through one access-controlled secure application.

02

TPS / AT Server

TPS / AT Command Server

Send an AT command to a device in the field and get a matched answer back over REST.

  • Connectivity
  • Cloud
  • Backend
Try the round trip

Stack Python · MQTT · AWS IoT Core · TLS · REST API · AWS EC2 · Linux

A caller posts an AT command to a REST API. The backend creates a request ID and publishes the command through AWS IoT Core over TLS to the device's topic. The device replies with the same ID, and the backend matches it and returns the answer. CallerREST BackendPython · EC2 AWS IoT CoreMQTT · TLS Devicedemo-0001 AT+CSQ + request_id …/at/req same request_id 200 OK match · validateor time out cleanly
Fig. 02 · One command, out and back

Problem

A device in the field has no inbox. To ask it anything, a command has to reach it over MQTT, and the answer has to find its way back to whoever asked.

Architecture

A REST API in front of a backend service that talks to devices through MQTT on AWS IoT Core, over TLS, with a command topic per device.

Engineering

Each request gets a UUID. The device replies with the same UUID; the backend validates the reply, matches it to the waiting request and returns it. No valid reply in time means a clean timeout, not a hung call.

Result

Real-time request and response on top of publish and subscribe messaging.

03

Dual Boot - A/B OTA

A/B firmware updates for an automotive and connected-device platform

Firmware updates that never leave the device without a working system to boot.

  • Device

99%lower boot failures

Stack Android · QCM2290 · A/B partitions · Boot flow · Recovery and fallback · Firmware validation

A/B update: the OTA package is written to slot B while the device runs from slot A. After validation, boot control switches to slot B and reboots. If slot B is not healthy, the device falls back to slot A. Boot control OTA package Slot Arunning systemknown good Slot Bnew image2 · validate current 1 · write 3 · boot B 4 · healthy? keep B 5 · not healthy: fall back to A
Fig. 03 · Two slots, one always bootable

Problem

A firmware update that fails partway can leave a device that won't boot (bricking).

Architecture

Two copies of the system, slot A and slot B, on Android for the Module (QCM2290). The device runs from one while the update goes to the other.

Engineering

Write the new image to the inactive slot, validate it, switch the boot target and reboot. If the new slot doesn't come up healthy, fall back to the slot that worked.

Result

99% lower boot failures.

04

Delta FOTA

Device firmware over the air for a connected embedded platform

Over-the-air firmware updates, built so a failed step never strands the device.

  • Device
  • Connectivity

60%faster OTA

Stack DFOTA · QCX216 · Firmware verification · A/B updates · Slot activation

DFOTA flow in four stages: deliver, verify, reboot, activate. If any stage fails, the device stays on firmware that works. 01020304 Deliverover the air Verifyimage checks Rebootcontrolled restart Activatenew slot live Any step fails: the device stays on firmware that works
Fig. 04 · A staged, fault-tolerant update flow

Problem

Firmware has to reach devices over the network, and an update that goes wrong can't be allowed to break them.

Architecture

A staged update flow on the IoT module (QCX216): deliver, verify, reboot, activate, built on limited memory constraints.

Engineering

Delivery, verification, reboot and slot activation are each designed so that a failure leaves the device on firmware that works.

Result

60% faster OTA.

05

Internal Dashboard Server

Operational visibility for connectivity validation workflows

A backend and dashboard that make device workflows visible and quick to run.

  • Cloud
  • Backend

One viewof device workflows and status

Scope Backend server · Dashboard · Operational views · Device workflows

A dashboard talks to an internal backend server, which runs connected-device workflows for demo devices and reports their status back. Dashboard cat1 stress functional Backendautomated intelligence Cellular tests BT tests WiFi tests
Fig. 05 · Dashboard, backend, devices

Problem

Device workflows and connectivity tests are hard to run well when nobody can see them.

Architecture

A backend server with a dashboard on top, built for internal validation teams.

Engineering

Operational views, test suite and connected-device workflows brought into one place.

Result

Device workflows and their status visible in one place, instead of spread across tools.

Interactive

Try the patterns yourself.

Three small simulations of patterns from my work. They run in your browser, and every device, ID, version and value in them is made up.

Experience

Roles so far.

Each role is tagged by the month it started, and the newest one runs in slot-A.

  1. v2025.03Slot A · running

    to present

    Cloud Engineer

    L&T Semiconductor Technologies Limited

    Cloud and backend systems for connected devices and smart modules, in connected mobility and automotive telematics.

    Changelog

    • AWS IoT Core and MQTT
    • Device provisioning and lifecycle management
    • Remote AT command execution and telemetry
    • GNSS/TPS positioning
    • OTA/FOTA
    • Backend APIs and cloud infrastructure

  2. v2024.01Slot B · previous

    to

    Software Engineer

    Buyerstage

    Backend and platform engineering: APIs and database-backed services, with a focus on getting backend workflows delivered faster.

    Changelog

    • API development
    • Database-backed services
    • Platform engineering

Capabilities

The stack, by layer.

Colour-coded the same way as the story above: the path a message takes, with security and tooling running under all of it.

01 · Device and embedded

  • Embedded C
  • MCU systems
  • QCM2290
  • QCX216
  • A/B partitioning
  • OTA and DFOTA
  • Secure boot concepts

02 · Connectivity

  • MQTT
  • TLS
  • Telemetry
  • Remote AT commands
  • GNSS/TPS

03 · Cloud (AWS)

  • AWS IoT Core
  • EC2
  • S3
  • Lambda
  • EventBridge
  • Device provisioning
  • Device lifecycle management
  • OTA/FOTA

04 · Backend

  • Java
  • JavaScript
  • Node.js
  • Spring Boot
  • Hibernate
  • JPA
  • Prisma
  • REST APIs
  • GraphQL
  • PostgreSQL

Security and identity

  • OAuth2
  • JWT
  • TLS
  • X.509 concepts
  • Secure provisioning
  • Identity and access management

DevOps and tools

  • Docker
  • Jenkins
  • Maven
  • Linux
  • Git
  • Postman
  • OpenTest

Connected mobility

  • 2W connected clusters
  • 4W entry-level IVI
  • Smart modules
  • Telematics
  • Automotive MCU
  • Worked with or studied: QCM2290, QCX216, RH850

Patterns I design with

The architecture side of nearly three years across backend, cloud and IoT work.

Messaging

  • Pub/sub over MQTT
  • Request-reply correlation
  • Timeouts and retries
  • Idempotent handlers
  • Event-driven workflows

Device fleets

  • Provisioning flows
  • Certificate-based identity (mutual TLS, X.509)
  • Device state and lifecycle
  • OTA with rollback

Backend architecture

  • REST and GraphQL API design
  • Relational data modelling and migrations
  • OAuth2/OIDC with role-based access
  • Layered services

Delivery and operations

  • Containerised services with Docker
  • CI/CD with Jenkins and Maven
  • Services on Linux and EC2
  • API testing with Postman

Education

Still learning the hardware side.

  • November 2025 to present

    M.Tech, Embedded Systems

    BITS Pilani

    Focus: embedded systems, connected devices and systems engineering.

  • Bachelor's degree

    B.Tech, Information Technology

    Dr. Mahalingam College of Engineering and Technology

    GPA 9.2

Contact

Have a device that needs to talk to the cloud?

Based in Bengaluru, India. Email is the fastest way to reach me. I'm also on LinkedIn and GitHub.