Component-Based Real-Time Operating System for Embedded Applications …d3s.mff.cuni.cz/teaching/seminars/2010-01-19-Loiret-ComponentBase... · Component-Based Real-Time Operating

Component-Based Real-Time Operating System forEmbedded Applications

Frederic Loiret

INRIA Lille - Nord Europe, Project ADAM

01/19/2010

Introduction

Context

Applying CBSE principles to improve flexibility in designing Real-Time andEmbedded (RTE) systems:

Application and Operating System tightly coupled

Constrained systems

Flexibility is addressed throughout the design flow

At design time

At runtime

Work conducted from a software engineering point of view

Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 2 / 22

Introduction

Contributions & challenges

Componentization of a legacy RTOS

A homogeneous component model

Used at OS & application levels

Introducing runtime flexibility

Be able to specify where runtime flexibility is needed

Minimizing performance issues

Memory footprint / Execution timeBe able to deploy what is strictly required by the application


Background

Outline

1 Introduction

2 BackgroundµC/OS-II RTOSThe Think component framework

3 Contributions

4 Quantitative Evaluation

5 Conclusion


Background µC/OS-II RTOS

µC/OS-II Real-Time Operating System (RTOS)

Preemptive, real-time multitaskingimplemented in C

Certified by the FAA(for software deployed in avionics equipment)

Mature RTOS used in many industrial projects

Provides basic RTOS features(implemented as a monolithic kernel)

Inter−Process Communication (IPC)

Global variables

Configuration constants

Data typesTimer Memory

MutexSemQueueMbox

TaskPort Core

FlagTime

µC/OS is a good candidate:

Mature & well modularized

Highly configurable

Determinist

Designed to be portable


Background The Think component framework

The Think component framework (1)

A C implementation of the Fractal component model, for embeddedsystems development.

general purpose, hierachical & reflective

distinction btw functional and ”control interfaces” (based on the Fractal API)

Think defines an ADL & an IDL:

component uCOS.time.lib.ATimeComponent extends AType {

// Public interfaces providedprovides uCOS.time.api.ClockCommon as clockprovides uCOS.time.api.DelayCommon as delay

// Internal interfaces requiredrequires uCOS.task.api.SchedCoreInt as schedcorerequires irq.api.IrqSafe as irqsafe// Attributes definitionattribute INT16U OS TICKS PER SEC = 100

content uCOS.time.lib.os time}

2

CI LCC

Control interfaces

irqSafe

schedcore

<<primitive>>

uCOS.time.lib.ATimeComponent

Configuration attributes

ProvidedFunctionalinterfaces

Required

Functional

interfaces1delay

clock

(1) delay interface signaturepublic interface uCOS.time.api.Delay {void OSTimeDly (INT16U ticks);

INT8U OSTimeDlyResume (INT8U prio); }(2) irqSafe interface signatureinternal interface irq.api.IrqSafe {void OS ENTER CRITICAL (void);

void OS EXIT CRITICAL (void); }




Think components’ implementation

Written in regular C (or wrapped assembler language)

The mapping between ADL symbols and C symbols specified using

annotations (in commentary sections)

// Attribute specification

// @@ DefaultAttributes @@

INT16U OS TICKS PER SEC;

// Required interfaces annotations

// @@ DefaultClientMethods(irqsafe) @@

// @@ DefaultClientMethods(schedcore) @@

// Implementation of provided methods

// @@ ServerMethod(delay, OSTimeDly) @@

void OSTimeDly (INT16U ticks) {// Call to a method of a required interface

OS ENTER CRITICAL();

// ...

}

schedcore

uCOS.time.lib.ATimeComponent

clock irqSafeProvidedFunctionalinterfaces

Configurationattributes

Required

Functional

interfacesdelay

<<primitive>>




Think compiler overview

Maps architectural elements to C variables in implementation codeProduces meta-data and implementations of control interfacesTransforms existing functional code

Generates C files compiled and linked by a C compiler

Optimized binary images generation with different performance vs.flexibility tradeoffs

constant attributesstatic bindingscode inlining

... etc


Contributions

Outline

1 Introduction

2 Background

3 ContributionsµC reengineeringComponent design at applicative levelRuntime flexibility support with Think


5 Conclusion


Contributions µC reengineering

µC reengineered as a component library (1)

Conducted in 6 steps

(1) Interface definitionsSpecified with Think IDL (according to theirnature / internal vs. public interfaces)

(2) Componentization Fine-grained componentization of the OS’services

Based on a coupling analysis between original µC modules



µC reengineered as a component library (2)

(3) Global variables @ALExpressed as component’s private data withset/getter interfaces

(4) OS configurationproperties

Specified using Think attributes

(5) Resources as components Tasks, semaphores, ... reified as components

(6) Component libraryOS components encapsulated within a compositeA set of OS configurations provided within thelibrary



A set of OS’ configurations provided by the library

OS’ configurations examples

ManagertaskInfo

irqSafe

contextSwitch

TimeTickComponent

timeTickHandlerirqSafe

interruptInfo

taskInfo

irqSafe

taskSchedInt

taskInfo

contextSwitch

contextSwitchInt

irqSafe

interruptInfo

itcUnlinktaskInfo

schedCore

ToTaskComp

ToInterruptComp

ToInterruptComp

ToTaskComp

ToTaskComp

ToInterruptComp

ToTaskComp

ToTaskComp

ToInterruptComp

ToTaskComp

ToTaskComp

AMinimalRTOS

<<composite>>

componentGeneric

component

Hardware−dependent

Legend

interruptInfo

taskInfo

schedcore

irqSafeTimeManager

taskInfo

interruptInfo

irqSafe

mboxPost

interruptInfo

taskInfo

irqSafe

semCreate

semPost

semPend

TaskManager

Component

Component

MailboxManager

Component

SemaphoreManager

Component

InterruptManager

Component

ISRCore

interruptInfo

InterProcessCommunication

schedCore schedCore

schedCore

Component

interfacesPublic

interfacesInternal

ItcUnlink

ItcInfo

init

init

taskCreate

taskResSusp

mboxCreate

delay

mboxPend

HwAbstractionComponent

ISRCore

taskInfo

timeTickHandler

irqHandlers

irqSafe


Contributions Component design at applicative level

Designing RT applications based on a two-levels approach

A homogeneus component model:

At operating system level

Components implementing low-level servicesExporting public services to the applicationRequiring interrupt handlers from the

application

At application level

A set of applicative and resource componentsRequiring low-level RTOS servicesProviding interrupt handlers

Classical composition between these two levels

Output a flattened architecture

Scheduling Task mgmt IT Mgmt

Time mgmt

Mem mgmt

Sem mgmt Mbox mgmt

Component-Based RTOS

ApplicativeComponent

Component-Based Application



Taskinstance

Taskinstance

Semaphoreinstance

Mailboxinstance

Services requiredby the application

Interrupts handlers


Contributions Component design at applicative level

Component design at applicative level

A typical Real-Time scenario

Shared data protected by a semaphore (with atimeout)

Periodic and event-based task activation

Inter-task communication by mailboxwrite2

3

1 1

3

SHAREDDATA

post

Mailbox

pend

release

acquireTASK 1

TASK 3

TASK 2[priority=30][priority=20]

[priority=10]

Semaphore[initialSize=1]

[timeout=4]

release

read

4

periodic event(period = 20 Hz)

external sporadic event

2

The same component model to design the application

Composition btwfunctional andresource components

Automatic bindingprocess with theRTOS

RTOS compositeexactly fits theapplicativerequirements

Legend

<<composite>>

AMinimalRTOS

irqHandler

mboxCreate

mboxPend

mboxPost

taskCreate

Task1Resrunner

taskCreate

taskResSusp

delay

delay

writeData

appSemPost

appSemPend

taskCreate

Task3Resrunner

Task3FunctionalCode

appMboxPend

Task2FunctionalCode

MailBox1Res

appMboxPend

appMboxPost mboxPend

mboxPost

mboxCreate

[priority=20]

[priority=10]

[priority=30]

[timeout=4] [initialSize=1]

runner

appSemPend

appSemPost

writeData

readData

SharedData

taskCreate

Task2Resrunner runner

Task1FunctionalCode

readData

appMBoxPost

appSemPend

appSemPost

taskResSusp

Semaphore1Res

semCreate

semPost

semPend

init

init

init

init

init

init

semCreate

semPost

semPend

RTOScomponent

Functionalcomponent

generatedautomatically

BindingsResourcecomponents

runner

irqHandler


Contributions Runtime flexibility support with Think

Runtime flexibility injection

Design/compilation flow

Comp-BasedApplication

Comp-BasedApplication

& RTOSLink toRTOS

C sourcefiles

Thinkcompiler

finalbinary

Flexibility-oriented properties

C compiler& linker

Flexibility-oriented properties

Tags on architectural artifacts

Aspect weaving techniques

Decoupled from the architecture’s specifications

Pattern matching rules

Runtime flexibiliy is embedded only where desired

Properties addressed by the compiler:

Meta-data generation which reify architectural artifacts at runtimeWeaving of Fractal API implementations

Optimizations



Properties injection examples

For a not flexible system :

component **.* {attribute * * [const]

}

component **.* {binds *.* to *.* [static]

}

component **.* {implementation * [shared=false]

}

component **.* {provides * as * [single=true]

}

RootComp

ServerComp

Server code

ClientComp

Client code




For a highly flexible system without Fractal API:

By default: meta-data generation

Metadata

Metadata

Metadata

Metadata

Metadata

Metadata

Metadata

Metadata

Metadata

Server code

ClientComp

Client code

RootComp

ServerComp




For a highly flexible system with Fractal API:

component **.* {provides fractal.api.AttributeController as att-controller if hasAttributecontent fractal.lib.ac if hasNoImpl(att-controller)

}component **.* {

provides fractal.api.BindingController as binding-controller if hasCltItfcontent fractal.lib.bc if hasNoImpl(binding-controller)

}

Metadata

Metadata

CI CI

CC

Metadata

CI

RootComp

Metadata

Metadata

Metadata

Metadata

Metadata

ServerComp

Server code

ClientComp

Client code

BC AC

Metadata




For a partially flexible system:

<ClientComp> component **.* {attributes * * [const=false]

}

component **.* {binds ClientComp.* to *.* [static=false]binds *.* to ClientComp.* [static=false]

}

CI

Metadata

Metadata

ServerComp

Server code

ClientComp

Client code

AC

RootComp

Metadata


Quantitative Evaluation

Outline

1 Introduction

2 Background

3 Contributions

4 Quantitative EvaluationMemory footprintsExecution time

5 Conclusion


Quantitative Evaluation Memory footprints

Memory footprints

Code & data overheads without Fractal API’s:

Reference Component-Based Design(a) (b) (c) (d)

highly flexible not flexible partially flexible

(1) RTOSCode 13 KB +16.8 % +0 % –Data 14 KB +3.26 % +0 % –

(2)Complete Code 14 KB +20.6 % +1.8 % +2.3 %

System Data 20 KB +4.59 % +0 % +0.5 %

Code & data overheads with Fractal API’s:

Reference Component-Based Design(a) (b) (c)

highly flexible partially flexiblewith Fractal APIs with Fractal APIs

(3) RTOSCode 13 KB +32.2 % –Data 14 KB +16.8 % –

(4)Complete Code 14 KB +47.8 % +4.1 %

System Data 20 KB +20.9 % +1.1 %


Quantitative Evaluation Execution time

Execution time

2 write2

3

1 1

3

SHAREDDATA

post

Mailbox

pend

release

acquireTASK 1

TASK 3

TASK 2[priority=30][priority=20]

[priority=10]

Semaphore[initialSize=1]

[timeout=4]

release

read

Execution path used for comparison

periodic event(period = 20 Hz)

external sporadic event

4

Monolithic Design Component-Based Designreference highly flexible not flexible

Execution Path (µs) 45.97 +2.8 % +1.3 %


Conclusion

Outline

1 Introduction

2 Background

3 Contributions


5 Conclusion


Conclusion

Conclusions

Flexibility at design time

Full CBSE support compared to a code-centric approachSame configuration capabilities than the original µC implementation

A dedicated OS built automatically according to application requirements

Design space provided for the application

Homogeneous component model

Resources as components

Clear view of the resources involvedDependencies btw resources and functional components reified atarchitectural level

Ease the configuration of the resources’ parameters

Flexibility at runtime

Aspects weaving only where required

Performance overheads

Null for not flexible systems

Or controllable in a fine grained manner


Component-Based Real-Time Operating System forEmbedded Applications

Frederic Loiret

INRIA Lille - Nord Europe, Project ADAM

01/19/2010

Documents

Component-Based Real-Time Operating System for Embedded Applications …d3s.mff.cuni.cz/teaching/seminars/2010-01-19-Loiret-ComponentBase... · Component-Based Real-Time Operating