TECS/Rust: Memory-safe Component Framework for Embedded Systems

TL;DR

The paper addresses memory-safety challenges in component-based embedded development by introducing TECS/Rust, a Rust-based framework for TECS that generates Rust code from TECS CDL descriptions and integrates with TOPPERS/ASP3. It combines Rust’s ownership and borrowing model with TECS’ CBD architecture and provides plugins and flows to produce memory-safe, low-overhead components that run on real-time OSes. Key contributions include automatic Rust code generation from CDL, a Rust plugin workflow for RTOS integration (including itron crate usage and Bindgen bindings), and an evaluation demonstrating minimal overhead and substantial code-reuse benefits. The work advances practical memory-safe CBD for embedded systems, enabling safer components without sacrificing performance or flexibility, and points to future interoperability improvements across languages and TECS features.

Abstract

As embedded systems grow in complexity and scale due to increased functional diversity, component-based development (CBD) emerges as a solution to streamline their architecture and enhance functionality reuse. CBD typically utilizes the C programming language for its direct hardware access and low-level operations, despite its susceptibility to memory-related issues. To address these concerns, this paper proposes TECS/Rust, a Rust-based framework specifically designed for TECS, which is a component framework for embedded systems. It leverages Rust's compile-time memory-safe features, such as lifetime and borrowing, to mitigate memory vulnerabilities common with C. The proposed framework not only ensures memory safety but also maintains the flexibility of CBD, automates Rust code generation for CBD components, and supports efficient integration with real-time operating systems. An evaluation of the amount of generated code indicates that the code generated by this paper framework accounts for a large percentage of the actual code. Compared to code developed without the proposed framework, the difference in execution time is minimal, indicating that the overhead introduced by the proposed framework is negligible.

Figures (19)

• Figure 1: System model.
• Figure 2: Signature description.
• Figure 3: Celltype description.
• Figure 4: Cell description.
• Figure 5: Component diagram.