What this is. Opinion + Experience + Fact (40% opinion · 20% experience · 40% fact). Written in collaboration with AI — I discuss, I do not outsource.

Every connected product rebuilds the same layer above the RTOS. We spent two decades doing it, then open-sourced the result — EmbedIQ, Apache 2.0. Here is what it is, the two ways teams use it, and exactly where it stands today.

There is a layer of embedded software almost nobody talks about, and almost everybody rebuilds. Below it sits the RTOS — FreeRTOS, Zephyr, bare-metal — doing its job of scheduling and timing. Above it sits your product. In between is the part that decides how your modules talk, who owns state, how the system is observed, how it updates, and how it proves it is secure. The RTOS leaves that layer to you, so every team writes it again, from scratch, on every project.

We spent two decades writing that layer for other people's products. Eventually we stopped rewriting it and turned it into one clean, open-source layer — EmbedIQ, under Apache 2.0. This post is the straight version of what it is and how teams use it: two doors, one honest status report, and an open invitation.

1. The layer above the RTOS — the one everyone rebuilds

Ask any embedded team what they rebuilt on their last three products and you will hear the same list: task structure, a message bus, a state-machine pattern, logging and telemetry, OTA, provisioning, cloud glue. None of it is the product. All of it is necessary. And because the RTOS deliberately stops at the kernel, that application architecture is left to each team to reinvent — which is why the same structural bugs show up across very different products.

EmbedIQ is that layer, made reusable. It is RTOS-agnostic by design: the same application code runs above FreeRTOS, Zephyr, POSIX/Linux, or bare-metal. Your firmware is built from Functional Blocks that own their own state and talk over a message bus, with a state-machine engine and observability underneath — the shape a portable, testable architecture has always needed.

▸ First principle. The substrate is not the problem; the layer above it is — so that is the layer worth standardizing and opening.

2. Door one — you build the device

The first door is for teams who ship firmware and want it structured, observable, and testable — no cloud required. Here EmbedIQ is simply the architecture layer above your RTOS, and its most immediate payoff is that it runs on your laptop — Linux, macOS, or a Linux Raspberry Pi. The same application code runs on a host and on the device, so you can clone the repo, run a couple of example systems — a thermostat, an industrial gateway — in a few commands, with no board, and watch the system actually move.

Because observability is zero-instrumentation, every event is captured as it happens: you see messages flow between blocks, state machines transition, queues fill — without adding a single printf. Debugging stops being archaeology. You catch the ordering bug on your laptop, in CI, before it becomes folklore on a customer's bench.

▸ First principle. Firmware you can run and see on a laptop is firmware you can debug before it ships.

3. Door two — you build a connected product

The second door is for teams whose device joins a fleet. The device architecture stays exactly the same; EmbedIQ Cloud adds the other half — provisioning, fleet monitoring, and staged OTA — on top of it. The point is that the device and the cloud speak one model, rather than two stacks bolted together at the seams, which is where most connected-product complexity actually hides.

That means the same Functional Block you debugged on your laptop is the unit you provision, monitor, and update across ten thousand devices. A telemetry event on the device is the same event you read in the cloud. One architecture, device to fleet.

▸ First principle. The device and the fleet should speak the same architecture, not meet at a brittle seam.

EmbedIQ — one architecture, two doors A central EmbedIQ architecture block splits into two doors: door one is the device path (runs on your laptop, RTOS-agnostic, observable); door two is the connected path (adds EmbedIQ Cloud for provisioning, fleet monitoring, and OTA). Both use the same device architecture. One architecture. Two doors. EmbedIQ Apache 2.0 · RTOS-agnostic core Door 1 — you build the device Runs on your laptop · no board Structured · observable · testable above FreeRTOS · Zephyr · bare-metal open source, today Door 2 — you build connected + EmbedIQ Cloud provisioning · fleet · staged OTA same device architecture, device to cloud invite-only, rolling out

4. Why we opened it — proof you can inspect

We released EmbedIQ under Apache 2.0 on purpose. Infrastructure you will depend on for a decade should be open enough to read before you trust it — and permissive enough to actually ship. That is also why the compliance story is structural, not a bolt-on: every Functional Block carries a safety_class field, the Observatory produces a tamper-evident .iqtrace audit trail automatically, and a CycloneDX SBOM comes out of the build. The evidence a regulation like the EU Cyber Resilience Act asks for is a by-product of the architecture — and you can verify all of it in the source.

To be precise about the boundary: EmbedIQ does not make your product certified — that remains your responsibility. What it does is put the structure and the evidence on your side of the line by default, in code you can inspect.

▸ First principle. Infrastructure you depend on for years should be open enough to inspect, and permissive enough to ship.

5. Where we are, honestly

Here is the straight status, because a pitch without it is not worth much. EmbedIQ Core is complete — engine, message bus, FSM engine, and full observability, contracts frozen and tests green on main. Phase 2 is active and already substantial: a metrics/telemetry block, typed configuration, cross-layer fault hooks, a test harness, and a six-Functional-Block industrial gateway example — all running today on Linux, macOS, or a Linux Raspberry Pi, with no hardware required. In flight now: the MQTT cloud block and the CLI; next come the on-MCU targets (FreeRTOS, ESP32). EmbedIQ Cloud and Studio are in invite-only early access.

In other words: the architecture is proven and public, the hardware and cloud layers are rolling out, and this is exactly the window where an early team's needs shape what ships next. If you have shipped production firmware and want a say in which targets and blocks come first, that is the most useful moment to show up.

▸ First principle. An honest status report is part of the offer — proof-first beats promise-first.

Two doors, one architecture, open source. If you are building an embedded product, a connected one, or just choosing the architecture before you start, we would genuinely like to compare notes — and if it helps, to help. Read the code, run the examples, and tell us what you need next.

Sources

EmbedIQ — the open-source (Apache 2.0) architecture layer described here: Functional Blocks, message bus, state-machine engine, zero-instrumentation observability, tamper-evident .iqtrace audit trail, CycloneDX SBOM, safety_class per block; host-first (runs on Linux today), RTOS-agnostic. EmbedIQ Cloud and Studio: invite-only early access. Code, architecture, and status are public — the links live on my profile.

FAQ

What is EmbedIQ?
EmbedIQ is an open-source (Apache 2.0), RTOS-agnostic architecture layer for embedded and edge systems — the structured application layer above the RTOS. It gives firmware Functional Blocks with single-owner state, a message bus, a state-machine engine, and zero-instrumentation observability, so the same application code runs above FreeRTOS, Zephyr, POSIX/Linux, or bare-metal.

Is EmbedIQ free and open source?
Yes. EmbedIQ Core is released under the Apache 2.0 license — a permissive license you can read, run, and ship. The code is public with no signup required to read it.

Does EmbedIQ run on real hardware yet?
EmbedIQ Core runs today on Linux, with all tests green and two example systems (a thermostat and an industrial gateway) you can clone and run in a few commands. Real-hardware targets such as FreeRTOS and ESP32 are the next phase, rolling out now.

What is EmbedIQ Cloud?
EmbedIQ Cloud is the connected half — provisioning, fleet monitoring, and staged OTA updates — built on the same device architecture, so a device and its fleet share one model. It is in invite-only early access.

How do I try EmbedIQ?
Clone the repository, run the example systems on your laptop (no hardware required), and read the architecture docs. Starring the repo and joining the discussions is how early teams shape which hardware targets and blocks are prioritized next.

The short version of this is on my LinkedIn. The framework is open source, Apache 2.0 — it's called EmbedIQ — and the code, the architecture, and the links live on my profile.