Upload
builiem
View
213
Download
0
Embed Size (px)
Citation preview
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 3 / 22
Background
Outline
1 Introduction
2 BackgroundµC/OS-II RTOSThe Think component framework
3 Contributions
4 Quantitative Evaluation
5 Conclusion
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 4 / 22
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 5 / 22
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); }
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 6 / 22
Background The Think component framework
The Think component framework (2)
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>>
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 7 / 22
Background The Think component framework
The Think component framework (3)
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 8 / 22
Contributions
Outline
1 Introduction
2 Background
3 ContributionsµC reengineeringComponent design at applicative levelRuntime flexibility support with Think
4 Quantitative Evaluation
5 Conclusion
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 9 / 22
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 10 / 22
Contributions µC reengineering
µ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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 11 / 22
Contributions µC reengineering
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 12 / 22
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
ApplicativeComponent
ApplicativeComponent
Taskinstance
Taskinstance
Semaphoreinstance
Mailboxinstance
Services requiredby the application
Interrupts handlers
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 13 / 22
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 14 / 22
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 15 / 22
Contributions Runtime flexibility support with Think
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 16 / 22
Contributions Runtime flexibility support with Think
Properties injection examples
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 16 / 22
Contributions Runtime flexibility support with Think
Properties injection examples
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 16 / 22
Contributions Runtime flexibility support with Think
Properties injection examples
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 16 / 22
Quantitative Evaluation
Outline
1 Introduction
2 Background
3 Contributions
4 Quantitative EvaluationMemory footprintsExecution time
5 Conclusion
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 17 / 22
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 %
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 18 / 22
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 %
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 19 / 22
Conclusion
Outline
1 Introduction
2 Background
3 Contributions
4 Quantitative Evaluation
5 Conclusion
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 20 / 22
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
Frederic Loiret ( INRIA Lille - Nord Europe, Project ADAM)DSRG seminar 01/19/2010 21 / 22