TECS/Rust-OE: Optimized Memory Safety for Embedded

• TECS/Rust-OE is a memory-safe, component-based framework that automatically generates Rust code from CDL to optimize exclusive control based on task call-flow analysis.
• It employs a two-pass generation flow that first produces baseline code and then refines synchronization by analyzing actual call flows, thereby reducing unnecessary locking overhead.
• The framework integrates Rust’s ownership, UnsafeCell, and RTOS primitives to selectively apply synchronization, enhancing performance and reusability in embedded system design.

TECS/Rust-OE is a memory-safe component-based development framework for embedded systems that extends the earlier TECS/Rust framework by optimizing exclusive control over mutable static component state. Its central objective is to preserve the reusability and structural separation of TECS while removing synchronization that is unnecessary under the actual task and call-flow structure of the system. The framework automatically generates Rust code from Component Description Language (CDL) specifications, extracts call flows from Entry Port Function Code, and then regenerates code and RTOS configuration so that only cells requiring synchronization retain exclusive control. The reported evaluation shows reduced overhead due to optimized exclusion control and high reusability of the generated code (Yoshimura et al., 29 Oct 2025).

1. Problem setting and motivation

TECS/Rust-OE is situated in the context of embedded systems that are becoming larger and more complex in IoT, automotive, and medical domains, while still requiring memory safety, real-time predictability, high reusability or modularity, and low overhead (Yoshimura et al., 29 Oct 2025). TECS/Rust had already proposed a Rust-based framework for TECS that preserves component-based development while leveraging Rust’s ownership, borrowing, and lifetime mechanisms and supporting efficient integration with TOPPERS/ASP3 (Yoshimura et al., 29 Oct 2025).

The specific problem addressed by TECS/Rust-OE is the cost of excessive exclusive control in the original TECS/Rust design. In TECS-style systems, components are represented as static structures with mutable variables. Rust requires such shared mutable state to be protected, and in the original framework this led to exclusive control being applied to all mutable statics, regardless of whether a given cell was actually shared across multiple tasks. The paper characterizes this as overly conservative: if a component is accessed only by one task, or if several components are used sequentially by the same task, locking is unnecessary, yet TECS/Rust still incurred the cost of lock and unlock operations and lock-related structure (Yoshimura et al., 29 Oct 2025).

A common misunderstanding is that the runtime cost arises primarily from componentization itself. The TECS/Rust and TECS/Rust-OE evaluations instead distinguish between the structural cost of the framework and the cost of synchronization. TECS/Rust reports that the framework’s overall overhead is small, while TECS/Rust-OE isolates unnecessary exclusive control as the principal source of avoidable performance loss (Yoshimura et al., 29 Oct 2025).

2. Foundation in TECS/Rust and TECS component modeling

TECS/Rust-OE inherits the TECS/Rust mapping from TECS CDL into Rust program structure. In TECS/Rust, signature, celltype, and cell descriptions are transformed by generator plugins into Rust traits, structs, static instances, and trait implementations. A signature becomes a Rust trait; a celltype becomes a Rust structure; and a cell instance becomes a static value. For RTOS integration, the framework uses RustGenPlugin and ItronrsGenPlugin, with a build flow involving the TECS generator, the ASP3 configurator, bindgen, Rust compilation, and linking with kernel object files (Yoshimura et al., 29 Oct 2025).

TECS/Rust-OE preserves this generation model but changes what is generated around mutable component state. The paper describes a Rust-side structure corresponding to a TECS celltype as a statically instantiated structure containing call ports, attributes, variable-related fields, and a field for exclusive control reference, ex_ctrl_ref. Call ports are typed using trait bounds corresponding to connected signatures. This means the optimization is not a redesign of TECS or of the Rust binding strategy; it is a refinement of how generated components manage exclusivity (Yoshimura et al., 29 Oct 2025).

This continuity is important because the framework’s claim is not merely lower overhead, but lower overhead without compromising reusability. The generated structure remains TECS-centric, with the optimization confined to auto-generated code rather than developer-authored component behavior (Yoshimura et al., 29 Oct 2025).

3. Two-pass generation flow and call-flow extraction

The defining architectural feature of TECS/Rust-OE is a two-pass generation flow. In the first pass, TECS component definitions written in CDL are translated into baseline Rust code. This generated code includes celltype structures, call ports, attribute fields, variable wrappers, and exclusive-control references. The developer then writes the component behavior in the generated Entry Port Function Code (Yoshimura et al., 29 Oct 2025).

The framework subsequently extracts call flow from that developer-written entry-port code. According to the paper, this extraction reveals which tasks access which cells, whether accesses are single-task or multi-task, and whether cells are used in sequence by the same task. The extracted call flow is then combined with the original CDL coupling information in a second run of the TECS generator (Yoshimura et al., 29 Oct 2025).

The second pass performs three actions: it removes unnecessary exclusive control, chooses the appropriate synchronization primitive, and generates the RTOS configuration file accordingly. In effect, TECS/Rust-OE uses static component structure from CDL and behavioral information from entry-port call flows to specialize synchronization to the actual execution pattern rather than to the mere presence of mutable state (Yoshimura et al., 29 Oct 2025).

A plausible implication is that TECS/Rust-OE treats synchronization synthesis as a code-generation problem rather than as a post hoc manual optimization problem. The paper does not present this as a separate formalism, but its workflow clearly makes the generated artifact depend on both structural and behavioral information.

4. Exclusive-control abstraction and memory-safety mechanism

The variable portion of a generated component is represented through a variable structure, a sync variable structure, and UnsafeCell. The actual data is placed in UnsafeCell to allow interior mutability, since Rust would otherwise reject externally immutable but internally mutable shared state. The paper is explicit that UnsafeCell alone is not thread-safe, so safety is restored by a custom exclusive-control abstraction (Yoshimura et al., 29 Oct 2025).

That abstraction consists of TECSMutexRef, TECSSemaphoreRef, and TECSDummyExCtrlRef, implemented using RTOS-level exclusive control mechanisms from the ITRON specification via the itron Rust crate. These are abstracted through a trait called something like LockManager, which provides lock and unlock operations. Component code therefore depends on an abstraction layer rather than directly on a particular RTOS primitive (Yoshimura et al., 29 Oct 2025).

The lifetime-bound safety discipline centers on get_cell_ref() and LockGuard. The paper gives the following usage pattern:

let (port, var, _lg) = self.cell.get_cell_ref();

Here, get_cell_ref() locks the protected variable structure and returns references to the ports, variables, and a LockGuard. LockGuard unlocks automatically in its destructor, so the exclusive-control interval is tied to the lifetime of the entry-port function execution. The reported consequence is safe access while the function runs, automatic unlocking on scope exit, and avoidance of manual unlock bugs (Yoshimura et al., 29 Oct 2025).

This mechanism clarifies the framework’s notion of memory safety. Safety is not obtained from UnsafeCell in isolation, but from the combination of Rust ownership rules, UnsafeCell for interior mutability, RTOS-managed exclusive control, and lifetime-bound LockGuard (Yoshimura et al., 29 Oct 2025).

5. Call-flow-based optimization rules and RTOS-aware synchronization selection

The optimization logic is defined through task access analysis. The paper states three core rules. First, if a cell is accessed only by one task, it does not need exclusive control. Second, if a cell is accessed by multiple tasks, it does need exclusive control. Third, if several cells are accessed sequentially by the same task, exclusive control can be removed from later cells, keeping it only for the first one (Yoshimura et al., 29 Oct 2025).

These rules are realized through three code-generation cases. When cells requiring and not requiring control coexist, the framework uses LockManager as an abstract ex_ctrl_ref, with TECSDummyExCtrlRef assigned to cells that do not need real locking. When all cells do not need exclusive control, the ex_ctrl_ref field is deleted entirely. When all cells need exclusive control, ex_ctrl_ref directly points to TECSMutexRef or TECSSemaphoreRef (Yoshimura et al., 29 Oct 2025).

The framework also selects between mutex and semaphore according to task access characteristics. If more than three tasks access the cell and they have different priorities, the framework uses a mutex with priority ceiling protocol; otherwise, it uses a semaphore (Yoshimura et al., 29 Oct 2025). This choice is notable because the optimization is not limited to binary lock removal. It also adapts the remaining synchronization to RTOS scheduling conditions.

A further misconception addressed indirectly by the paper is that Rust’s safety model determines the minimal synchronization pattern automatically. TECS/Rust-OE shows that, in a componentized embedded setting with static structures and generated code, the safe design space may still contain unnecessary synchronization, and that recovering the minimal necessary control requires explicit call-flow and task-access analysis (Yoshimura et al., 29 Oct 2025).

6. Evaluation: execution time, code generation, and reusability

The evaluation considers execution time or overhead and code size or hand-coding effort. The reported environment is TOPPERS/ASP3 on STM32F413VG, using the SPIKE-RT application benchmark and the APIs get_distance, stop, and set_speed. The comparison includes ordinary Rust, TECS/Rust before optimization, TECS/Rust after optimization, and variants with and without RTOS exclusive control (Yoshimura et al., 29 Oct 2025).

The paper reports that TECS/Rust without exclusive-control changes has no noticeable execution-time difference from ordinary Rust, indicating that componentization itself does not add overhead. It also reports that dynamic dispatch in the framework did not affect execution time. The major difference instead comes from exclusive control operations: when exclusive control is present, execution time increases; when unnecessary exclusive control is removed, overhead drops. The paper therefore attributes the main performance improvement of TECS/Rust-OE to eliminating lock and unlock overhead rather than to changing the component abstraction (Yoshimura et al., 29 Oct 2025).

The reported code metrics are as follows:

Category	TECS/Rust Before	TECS/Rust After
CDL File	24	0
Auto-generated Code	629	588
Written Code	196	0
Hand-coding	220	0
Compiled Code	825	784

The paper interprets these numbers as evidence that the optimization affects only auto-generated code. It emphasizes that after optimization the written code drops to 0, and that hand-coding after optimization becomes a perfect zero. This is presented as evidence of high reusability, a smooth generation-to-optimization workflow, and reduced developer burden (Yoshimura et al., 29 Oct 2025).

The evaluation is qualitative with respect to performance improvement magnitude: the paper does not provide a numeric speedup in the supplied text, but it states that the largest gains come from eliminating lock and unlock overhead and that the optimized framework improves predictability, especially when a component is reused many times (Yoshimura et al., 29 Oct 2025).

7. Assumptions, limitations, and position within Rust systems research

TECS/Rust-OE assumes that component coupling is statically described in CDL, that Entry Port Function Code can be analyzed to extract call flow, that the system uses a TECS-style static component structure, that RTOS-level exclusive-control primitives are available, and that the embedded environment supports Rust and the itron ecosystem. It is targeted at embedded systems, IoT devices, RTOS-based systems, and potentially multi-core systems (Yoshimura et al., 29 Oct 2025).

The paper does not present an extensive limitations section, but it states or implies several constraints. Optimization depends on accurate call-flow extraction; the framework relies on static component descriptions and static analysis of usage patterns; and the evaluation is limited to a small SPIKE-RT application on a specific STM32 board. The text further indicates that broader validation on more complex, larger-scale systems would be needed (Yoshimura et al., 29 Oct 2025).

Within Rust research, TECS/Rust-OE occupies a specific niche: performance-aware code generation for memory-safe embedded CBD. Other recent work focuses on adjacent assurance problems. Cargo Scan treats third-party crate auditing as an effects problem and reports that it can automatically classify 3434 of the top 10K crates on crates.io as safe or pure (Zoghbi et al., 6 Feb 2026). FourFuzz targets fuzzing effort toward functions that can reach unsafe Rust and reports 15% more unsafe code locations on average than afl.rs (Paaßen et al., 5 May 2025). Gillian-Rust and Creusot divide end-to-end verification between powerful automated verification of safe Rust and targeted semi-automated verification of unsafe Rust (Ayoun et al., 2024). KRust provides a formal executable operational semantics for a realistic subset of Rust, explicitly modeling ownership, moves, borrows, and lifetimes in K (Wang et al., 2018).

This suggests that TECS/Rust-OE belongs to a broader Rust systems agenda in which memory safety is necessary but not sufficient: generated embedded software must also control synchronization cost, dependency risk, unsafe-code exposure, and verification burden. TECS/Rust-OE’s contribution within that agenda is narrowly defined but technically specific: it makes exclusive control selective instead of universal in a TECS-based Rust component framework, while keeping memory safety and component reuse intact (Yoshimura et al., 29 Oct 2025).