Component-Based Real-Time Operating System for Embedded Applications

Abstract

Abstract. As embedded systems must constantly integrate new functionalities, their developement cycles must be based on high-level abstractions, making the software design more flexible. CBSE provides an approach to these new requirements. However, low-level services provided by operating systems are an integral part of embedded applications, furthermore deployed on resource-limited devices. Therefore, the expected benefits of CBSE must not impact on the constraints imposed by the targetted domain, such as memory footprint, energy consumption, and execution time. In this paper, we present the componentization of a legacy industry-established Real-Time Operating System, and how componentbased applications are built on top of it. We use the Think framework that allows to produce flexible systems while paying for flexibility only where desired. Performed experimentions show that the induced overhead is negligeable.

Minimal yet effective reconfiguration infrastructures in component-based embedded systems

“…Scenario 1, our standard highly flexible system, uses 61% more memory space than the static, not reconfigurable scenario 5. This confirms previous results in [20,21] and ratify the need of producing a lighter infrastructure for system evolution. Scenario 2 data show that architectural optimizations only reduced memory footprint size by 1,57%.…”

“…We designed a component-based operating system, similar to the one presented in [21], based on the Fractal component model and the Think framework. The NxOS project [2] provided us with legacy code for basic clock and interruption management as well as for a set of external peripherals control.…”

“…Even if Code section is traditionally bigger than Data, it is possible to find applications where Data section weight is more relevant (see [21]). Also, in order to take advantage of CBSE benefits at design and development time, fine granularity levels are required; a higher number of components implies more component meta-data to be embedded in final binary file, implying a bigger Data section, which may significantly reduce the impact of control interfaces implementation sharing.…”

Optimizing sensor network reprogramming via in situ reconfigurable components

“…Finally, Think [Fassino et al 2002] is a C implementation of Fractal [Bruneton et al 2006] whose main goal is to provide fine-grained reconfiguration at architecture-level. Think shares with RemoWare the capability to specify at compile time a subset of application's artefacts susceptible to be reconfigured [Loiret et al 2009], even though it comes with a high overhead per reconfigurable component. It would be possible to implement more efficient optimizations within Think related to the way dynamic interactions are reified at run-time.…”

A Hardware/Software CBSE Framework for RTOS Services: The Timing Service Case Study

“…Based on THINK framework [2], we proposed in [3] a componentization from an existing and mature RTOS μC/OS-II and its software implementation. At design time, we fully addressed, through out this componentization, the adaptation capabilities to get an efficient system.…”