Component-Based / Message-Driven Architecture

Overview

Architectural style that decomposes firmware into autonomous components communicating via messages or events instead of shared memory. Common implementations include actor models, message-bus middleware (Zenoh, Cyclone DDS, ROS 2 nodes), and OS-level component frameworks (Zephyr device model, ESP-IDF components).

Benefits

• Easier to reason about timing and concurrency than shared-state designs
• Components can be developed, tested, and replaced independently
• Naturally maps to multi-MCU and multi-core systems
• Enables in-process simulation by swapping component back-ends

Limitations & Risks

• Message overhead can be costly on tight memory/CPU budgets
• Event ordering and back-pressure require careful design
• Tooling for tracing message flow across components is still uneven

Recommended Actions

Prototype one self-contained subsystem (sensor pipeline, comms stack) with a message-driven architecture, measure the overhead vs. a shared-state baseline, and decide whether the maintainability gain justifies the cost before applying it broadly.

Additional Notes

Replaces the prior 'Microservice Architecture for Embedded' framing — true microservices imply cloud-native runtimes that don't fit firmware constraints. Pairs naturally with simulation-first workflows since component boundaries make swap-in simulators trivial.

References & Links

• https://zenoh.io/
• https://www.eclipse.org/cyclonedds/
• https://docs.ros.org/
• https://docs.zephyrproject.org/latest/services/device_mgmt/index.html