Fusion · Hardware separation

Your application. Its own processor.

The application MCU can focus entirely on product behaviour. Fusion puts communication, security and lifecycle work on a separate microcontroller, giving timing-critical applications dedicated CPU, memory and peripherals. For mission-critical devices, that separation supports predictable timing and reliable operation.

Independent resources. Focused execution.
Dedicated application MCU 100% application focus Own CPU, memory, peripherals and scheduling
Separate communication & security MCU RIoT Secure client Own processing resources for communication and lifecycle work
Fleet management & integration

Full focus on your application.

Fusion is RIoT Secure’s hardware sandbox architecture. Customer application firmware runs on its own microcontroller, with CPU, memory and peripherals dedicated to the job the device needs to do. The communication and security engine uses a separate processor’s resources.

Security handshakes, network processing and lifecycle operations run in that separate execution domain. The application team retains its own scheduling, toolchain and programming model, with a defined interface to the lifecycle infrastructure. This puts application execution at the centre of the hardware design.

Two processors. Defined responsibilities.

Application execution

Fusion dedicates the application MCU’s CPU, memory and peripherals to customer firmware. Communication and security tasks use a different processor’s resources, leaving the application team in control of scheduling and time-sensitive behaviour.

Use the language, framework and toolchain supported by your chosen application hardware: bare-metal firmware, an RTOS, real-time control, signal processing or local AI. Fusion provides the hardware boundary while developers choose the programming model that fits their product.

Communication & lifecycle

The RIoT Secure client runs on the separate communication and security MCU. It handles secure communication, provisioning, device identity and lifecycle operations. µTLS protects device-to-backend exchanges, while Oasis supplies the fleet management layer.

This split keeps communication workloads and lifecycle maintenance within their own execution domain. Application logic and communication firmware can evolve at different rates, with integration centred on the interface between the processors.

Fusion architecture: sensors and actuators connect to the customer application MCU; a separate communication MCU connects to the backend through µTLS. The diagram also shows the inter-processor connection and application programming path.
Application processing separated from communication and lifecycle operations · View full-size diagram

Timing you control. Reliability you design for.

For mission-critical applications, predictable execution is part of the device’s job. Control loops, sensor sampling and actuator responses can have specific timing requirements. Fusion keeps application processing on a dedicated MCU, while communication and security work executes on a separate processor.

This gives engineers a defined hardware domain in which to design, measure and validate application timing and reliability. Over a long service life, application firmware and the communication stack can follow their own development and maintenance cycles, with change managed at the interface between them.

RIoT Secure Fusion reference shield with Arduino-compatible headers, communication-module connections and an application programming interface.
Fusion Arduino-compatible reference shield · View full-size image

Start with familiar tools. Evaluate the architecture.

An Arduino-compatible starting point.

RIoT Secure’s Fusion reference shield makes the hardware sandbox practical to evaluate. A dedicated communication and lifecycle MCU works alongside an Arduino-compatible application processor, so developers can prototype with familiar tools while keeping application execution separate.

Use it to explore secure communication, provisioning and lifecycle operations, and to observe application timing while communication tasks run on the other processor. The reference board is a starting point: production designs can choose different microcontrollers, peripherals, toolchains and bare-metal or RTOS environments while retaining the same separation of responsibilities.

The hardware split. Already on the board.

The Arduino UNO R4 WiFi combines a Renesas RA4M1 Arm Cortex-M4 application processor with an ESP32-S3 communication processor. Fusion can use that existing two-processor arrangement without an external reference shield. The ESP32-S3 runs communication and lifecycle functions while the RA4M1 remains dedicated to application logic and peripheral control.

This provides another path from evaluation to implementation using the same architecture. Fusion is defined by the separation of application and communication responsibilities, rather than a particular board or form factor.

A hardware foundation for the whole lifecycle.

Fusion provides the hardware separation within the wider RIoT Secure platform. The communication and security MCU connects application devices to provisioning, protected data exchange, software delivery and fleet operations, while customer firmware retains its own execution environment.

Brawl adds a WebAssembly execution option for portable application logic. Its software sandbox and Fusion’s physical separation address different execution requirements; teams can select or combine them around the application and hardware design while using the surrounding lifecycle infrastructure.

Design the boundary. Build your device.

Fusion gives developers their own application execution domain and a hardware foundation for long-term device lifecycle management.