Shared platform · Device & edge

Firmware SDK

Every connected thing the group builds runs on the same firmware foundation: a hardware abstraction layer, a tested driver set, a secure bootloader and an over-the-air update path. A flight controller, an irrigation RTU and a battery management board are different applications on one base, which is why a fix to the update path benefits all three at once.

How determinism shows up here

Worst-case execution budgets are declared per task and checked in test, not inferred from average behaviour on a good day.

What it does

Inside the platform

Hardware abstraction & drivers

A tested driver set across the MCU families we standardise on, so a new board starts from a working base rather than a blank main().

Secure boot & signed images

Chain-of-trust from bootloader to application, so a device will not run firmware the group did not sign.

Over-the-air update

Fail-safe update with rollback, designed for devices that are physically unreachable once deployed.

Deterministic task structure

A task and timing model with declared worst-case budgets, so real-time behaviour is designed rather than measured after the fact.

How it fits together

The shape of the work

Hardware and firmware, gated on both sides

Every design step on the way down has a matching verification step on the way up. Nothing moves to production until the step opposite it has evidence behind it.

Who builds on it

Used across the group

Vyovrinda flight and avionics boards
Sasyaveda field controllers
Savithru battery management
Smart Infrastructure RTUs and gateways

Ownership

A shared platform. It has no natural home in any single unit, so the group funds it centrally and the shared engineering bench maintains it. Every company and division draws on the same version.

How we decide what is shared

Building something that needs Firmware SDK?

Tell us the constraints and we will come back with how this platform would carry them — or say plainly if it would not.

Start a conversation