EmberNET
EmberRTOS

The OS your factory floor deserves.

An immutable real-time operating system for the edge node. Locked down, auto-rollback patched, hardware-lab tested, and shipped with the Plasma firewall built in. It is EmberNET’s own OS, with its own real-time kernel.

  1. 01

    Immutable by design

    No config drift, no tampering, no mystery changes between shifts. EmberRTOS is locked down and identical every time it boots. What you deployed is what runs, period.

  2. 02

    Real-time capable

    Built for the timing demands of industrial control, not adapted from a desktop OS. Deterministic scheduling, predictable latency, and the headroom industrial workloads actually need. Turn the real-time kernel on for the machines that need it; the measured results are below.

  3. 03

    Built-in patching with auto-rollback

    Updates are tested in our hardware lab on every platform we deploy before they ever reach your site. If an update fails, EmberRTOS rolls back automatically. No bricked systems, no emergency truck rolls.

  4. 04

    Plasma

    A Linux firewall container built into EmberRTOS that handles network distribution and segmentation at the OS layer. It replaces dedicated firewall appliances with software-defined protection that deploys with every node.

  5. 05

    Hardware lab tested

    We maintain a physical lab with every piece of hardware EmberNET deploys on. Every update is validated on real hardware before it ships. Not VMs. Not simulations. Your actual hardware.

Measured, not claimed

23 µs worst case, over 24 hours and 627 million wake-ups.

Real time is a promise about the worst case, so that is the number we measure. On ARM64, on a Raspberry Pi 5 with the real-time kernel switched on, EmberRTOS held a 23 µs worst-case wake-up latency for a full day under load, four to nine times inside the 100 to 200 µs budget an industrial control loop needs.

EmberRTOS on ARM64, real-time kernel on

Worst-case wake-up latency, measured on a Raspberry Pi 5 (Cortex-A76)

23µs

Worst case, across every thread.

627,428,572

Wake-ups measured, and not one of them late by more than that.

24 h

Continuous, under load, with the board running from 30 °C up to about 60 °C.

Industrial target band, 100 to 200 µs 0 µs 50 µs 100 µs 150 µs 200 µs 250 µs T0 17 µs worst, every 200 µs T1 20 µs worst, every 700 µs T2 23 µs worst, every 1200 µs

Average, 1 µs on every thread Worst case

Measured with cyclictest: three SCHED_FIFO priority-99 threads, one per real-time core, with the stress load pinned to the housekeeping core. That is the isolation working as designed, not an all-core stress test. The 5 minute run gave 12 µs; the tail grew to 23 µs over 24 hours, which is exactly why the soak is the number that counts.

Every thread, every sample

ThreadIntervalSamplesMinimumAverageWorst case
T0 200 µs 432,000,000 1 µs 1 µs 17 µs
T1 700 µs 123,428,572 1 µs 1 µs 20 µs
T2 1200 µs 72,000,000 1 µs 1 µs 23 µs

How it was run

cyclictest with three SCHED_FIFO priority-99 threads, one on each real-time core, for 86,423 seconds. The housekeeping core carried the load: hackbench, two CPU-burn loops and a tmpfs memory streamer, pinned to the housekeeping core.

Heat didn’t move it

The board started at 30 °C, peaked around 60 °C and finished at 58 °C. No throttling, and the tail held while it ran hot.

Why the long soak matters

A five minute run on the same board gave 12 µs. Rare tail events live in the hours, not the minutes, which is why the 24 hour figure is the one we stand behind.

The stress load was pinned to the housekeeping core, so the real-time cores stayed isolated, which is how a production node is configured. It is not an all-core adversarial test. Results are per board and are not compared across architectures.

On x86-64 too

42 µs worst case on a commodity 4-core Intel machine.

The same real-time kernel, tuned, with the housekeeping core saturated by load, measured an average of about 1 µs and a worst case of 42 µs over a five minute run on unremarkable desktop silicon. That is more than four times inside a 200 µs control-loop budget and still more than twice inside a 100 µs one.

Real-time coreAverageWorst case
cpu11 µs36 µs
cpu21 µs42 µs
cpu31 µs31 µs

Want EmberRTOS running in your plant?

Talk to engineering about a deployment, from one Industrial PC to every line.

Request a demo