Embedded Components CDUF 2002 i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e © 2002 Markus Völter. - 1 - Embedded

Embedded Components CDUF 2002

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e www.voelter.de © 2002 Markus Völter. - 1 -

Embedded Embedded Components Components

Component InfrastructuresComponent Infrastructuresfor embedded and small systemsfor embedded and small systems

Markus Vö[email protected]



Contents

• Introduction

• Component Technologies

• The Target Platforms

• Current embedded systems architecture

• Product Line Engineering and Generative Programming

• Concepts of the Small Components Infrastructure

• The Prototype

• Example from the Automotive Domain



Contents

• Introduction






• The Prototype




What is a component infrastructure

• Most important principle: Separation of Concerns

• Functional concerns of an application are factored into reusable Components

• Technical concerns are provided by a standardized entity, a so-called Container

• Components are accessed only through a Component Interface

• Functionality of a Component is well defined, thus reusable.

C lient

...

C onta iner

Com

pone

nt 1

Com

pone

nt 2

Com

pone

nt 3



What is a component infrastructure (II)

Client Application

Client P rogram

A PPLICATION S ERVER

SE S S IO N

C O M P O N E N T 1

CO N T A IN E RINSTANCE P OOLING

CO N T A IN E R

A S S E M B LY P A C K A G E

CO M P O N E N T P A C K A G E

CO M P O N E N T

IM P LE M E N T A

-T IO N

CO M P O N E N T

IN T E R FA C E

supportfile

supportfile

supportfile

supportfile

supportfile


CO M P O N E N T

IM P LE M E N T A

-T IO N

A N N O T A -T IO N S

CO M P O N E N T

IN T E R FA C E

supportfile

supportfile

supportfile

supportfile

supportfile


C O M M O N

C O N FIG -U R A T IO N


CO M P O N E N T

IM P LE M E N T A

-T IO N


CO M P O N E N T

IN T E R FA C E

supportfile

supportfile

supportfile

supportfile

supportfile

C O N T A IN E R

Security Manager

CLIE N T

L IB R A R Y

C OMPONENT B US

CO M P O N E N T

C O M P O N E N T

IM P LE M E N T A T IO N

Business Operations

L IFE C Y C LE CA LLB A C K

Operations

CO M P O N E N T HO M E

Operations

CO

MP

ON

EN

T

INT

ER

FA

CE

S ERVICE

C OMPONENT

S ERVICE

C OMPONENT

S ERVICE

C OMPONENT

S ERVICE

C OMPONENT 1

S ERVICE

C OMPONENT

S ERVICE

C OMPONENT

S ERVICE

C OMPONENT

S ERVICE

C OMPONENT 2 Legacy App

E N T IT Y

CO M P O N E N T 1{ID=0815}

E N T IT Y

CO M P O N E N T 1{ID=4711}

Database

S E S S IO N

CO M P O N E N T 1

S E S S IO N

CO M P O N E N T 1

S E S S IO N

CO M P O N E N T 1

operation nam e andparam eters

IN V O C A T IO N CO N T E X T

transaction contextsecurity context

PR IM A R Y

KE Y

PR IM A R Y

KE Y

G LU E C O D E LA Y E R

C O M P O N E N T

P R O X Y

CO M P O N E N T

CO N T E X T

Transaction Manager

CO M P O N E N T

IN S T A LLA T IO N

operations &param eters

hom e operations

com ponent nam e

CO M P O N E N T

IN T R O S P E C T IO N

V IR T U A L IN S T A N C E

PASSIVATION

E NTITY

C OMPONENT

E NTITY

C OMPONENT

E NTITY

C OMPONENT

C OMPONENT

H OME

SE S S IO N

CO M P O N E N T 1

SE S S IO N

CO M P O N E N T 1

Com plex

Subsystem

M A N A G E D RE S O U R C E S

ResourceResource

ResourceResource

N AMING

com m ycom pany com ponen ts C om ponen tA C om ponen tB resou rces R esou rceX R esou rceY

CO N FIG U R A T IO N

P A R A M E T E R S

nam e1 - value1nam e2 - value2

...nam en - valuen

ResourceAdapter

PLU G G A B LE

RE S O U R C E S

RE

QU

IRE

D I

NT

ER

FA

CE

S

Client Application

HA N D LE

!

!S Y S T E M

E R R O R S



Component Infrastructures

• System functionality is separated into components:

• Components are then hosted in a container that handles technical concerns for them:

Component 1(Feature 1)




Feature 1

Feature 2

Feature 3

Feature 4

Client

...

Container

Com

pone

nt 1

Com

pone

nt 2

Com

pone

nt 3




• A component has a well-defined and separated interface.

• Container handles the lifecycle of components:

CONTAINER

COMPONENT

COMPONENT

IMPLEMENTATION

LIFECYCLE CALLBACK

operations:activate()passivate()

Client

does not exist method-ready

create component

remove componentbusinessmethod

passivated

passivate()

activate()

LIFECYCLE CALLBACK Operation




• To adapt the container to the specific components deployed in it, there usually needs to be a glue-code layer.

• It is generated from annotations, that specify how the container should handle the component(s).

CONTAINER

CO

MP

ON

EN

T

PR

OX

Y

GLU

E-C

OD

E-L

AY

ER

COMPONENT

Instance

CO

MP

ON

EN

T

INT

ER

FA

CE

LIFECYCLE CALLBACK

Interface

COMPONENT

Instance

ANNOTATIONS

transactionssecuritynaming

threading

Client



What is a component

• Additional properties of the kinds of Components we are interested in:

• a component is coarse grained

• principle of separation of concerns is employed

• Components can be accessed remotely

“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.”

Definition by Szyperski



Components in the Enterprise

• There are several popular component architectures in the enterprise environment:

• Enterprise Java Beans (EJB), a Java-only component model that is part of the Java 2 Enterprise Editition

• Micorsoft's COM+, a widely-used component architecture limited to Windows operating systems.

• CORBA Components (CCM), a component-extension to OMG's object request broker technology,

• Many other component architectures that have been designed specifically for a specific system



Benefits: Why are they successful?

• A Typical application structure:

• database contains business data

• processes that manipulate this data

• usually in the context of transactions.

• It is relatively easy to separate the functional from the technical concerns, and they can be implemented generically.

• Standards and commercially available containers

• People and their skills suit the seperation of concerns well

• Standardized, well documented Programming Model



Contents

• Introduction






• The Prototype




Target Platform Devices

• We consider the following kinds of devices to be „small systems“:

• Mobile Phones

• PDAs, Organizers

• Embedded computers, such as controllers or ECUs in vehicles orairplanes



Platform Characteristics

• Non-homgeneity, almost every device is different (in contrast to enterprise systems)

• Limited memory, only some hundred kB or some MB are available

• Limited computing power because the device often contain only small processors

• Limited electrical power because the device might be battery powered

• Timing requirements can be more stringent:• No real time• Soft real time• Hard real time (out of scope!)

• Network connection can either be permanent or intermittent



Contents

• Introduction






• The Prototype




Typical Software Architecture Today

• An OS Abstraction Layer hides some of the details of the underlying (realtime) operating system.

• A more sophisticated approach,especially for product families, isthe use of a framework – provides reuse for repeating aspects.

O perating System

OS Abstraction Layer

Application

O perating System

O S Abstraction Layer

Fram ew ork

Application



Embedded Architecture with Components

• Using a component container is basically a framework thatuses separation of concernsand optionally generative techniques.

• Reuse is simplified by only accessing components through their interfaces.

• OS Abstraction Layer + Framework + Separation of Concerns + Reuse = Component Architecture

O perating System

O S Abstraction Layer

Container

Com-ponent

Com-ponent

Com-ponent



Goal: Componentized Embedded OS

• In a last step, the container and the OS Abstraction Layer, as well as the operating system can be integrated to improve performance and reduce footprint even more.

Container

+ OSAbstraction Layer+ Operating System

Com-ponent

Com-ponent

Com-ponent



Challenges for Components

• Platform independent

• The concepts should be independent of the OS and implementation language

• Alternatively, the implementation should be done in a platform-independent programming language (such as Java)

• Simple and lightweight.

• A component infrastructure must be much simpler than e.g EJB or CCM

• Focus on the really important pieces of functionality

• Modular.

• Underlying hardware and OS will not support all features provided by the embedded components infrastructure.

• Thus, not all containers need to provide all possible features.

• Container features must be „pluggable“.



Challenges for Components (II)

• Reflective.• Components must know what their requirements are

regarding the container and • containers must know what features they provide to the

components• This is necessary to improve reliability

• Network-aware.• Different network transport protocols must be pluggable

without changing the component implementations (CORBA, Sockets, RMI, ...)

• Performance.• It is not acceptable to impose big performance overheads

into the system. • In contrast to enterprise systems, you cannot easily add

more and more hardware resources.



Contents

• Introduction






• The Prototype




Software Product Lines

• Instead of developing one single system, development focuses on a family of related systems. Reasons:

• different target platforms (operating system, middleware)

• different quality of service (QoS) requirements,

• potential for future growth

• Systems are built from product-specific parts and reusable parts: the common platform

• Creation of concrete systems should be done with the help of a (semi-)automatic assembly process

• industrialized production of software

• „build software like they build cars“



What is a software system family?

• A set of programs

• related through their common properties

• And distinguished through their specific properties

We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members.

Definition by Parnas, 1976



Product Line Engineering

• Domain Scoping

• Variability Analysis

• Domain Structuring

• Define common architecture

• Define Production Plan

• Define Building Blocks

• Components

• DSLs & Generators

• Production Process

Dom ain Analysis

Dom ain Design

Dom ainI m plem entation



Example Family (Feature Diagram)

• Example products:

• An aircraft with a low wing, piston engine and made of metal, wood and cloth: Robin DR-400

• An aircraft with shoulder wing, no engine and made of plastic: ASW-27

• An aircraft with low wing, jet engine(s) and made of metal: Airbus A320

Engine

A ircraft

W ing

high shoulder low J et Piston

m andatory optional

alternative( 1 of m )

or (n of m )

Materials

w oodm etal cloth plastic

m andatory

or (n of m )



More features of Feature Diagrams

• They can contain constraints on the combinations of features

• They can define „names“ for specific combinations of features; feature groups

• Features can be open: additional subfeatures can be added

• Features can be incomplete: the subfeatures are not yet defined

• Multiplicity of subfeatures can be added

• And more...



Features and Binding Times

• A feature diagram defines the common and variable aspects of a system. It has to be defined, when the variable aspects are fixed for a particular product.This is called binding time.

• Usually, binding time has consequences on

• flexibility

• performance

• code size

• type safety

• and: on the technique used to implement the variable aspect



Typical Binding Times

• source time: manual programming, template parameters

• compile time: function overloading, precompiler, template evaluation

• link time: DLLs, class loading

• run time: virtual functions, inheritance & polymorphism, factory-based instance creation, delegation

• deployment/configuration time: component deployment (impl. for an interface), environment variables



Consequences of Binding Times

source tim e

flexibility perform ance

com pile tim e

load tim e

link tim e

run tim e

code size

- + +

+ + +

+ + +

++ + +

+++ - -

com plexity

-

-

-

+

+



Generative Programming

Generative Programming …

is a software engineering paradigm based on modeling software system families such that, given a particular requirements specification, a highly customized and optimized intermediate or end-product can be automatically manufactured on demand from elementary, reusable implementation components by means of configuration knowledge.

Definition by Eisenecker & Czarnecki

ConfigKnowledgeD efaultsD ependenc iesIllega l combina tionsProduc tion P lanO ptimiza tions

Solution SpaceElementa ty componentsH ighly combinableN on-redundantArchitec ture o f the so ftware sys tem family

Problem SpaceFea turesD omain-spec if ic te rms



Contents

• Introduction






• The Prototype




Small Components and Product Lines

• With respect to components and containers, there are two things that can be considered a family, and created using GP:

• Components, their assembly and applications:This is the traditional way of using components & containers in the context of GP. •The container is a stable, fixed framework•Components are either (partly) generated and deployed,•or components are developed manually and GP provides

selection, assembly, “wiring” and deployment in the container.

• The container itself: This approach is used in embedded, resource constrained systems•The components are developed manually •The container is custom-generated “around” the components

to provide resource-optimized management of technical concerns



Small Components and Product Lines (II)

• Components are developed manually (or, later, generated) adhering to specific interfaces.

• The container which provides the infrastructure to the components is automatically created,

• Based on the



Small Components and Product Lines (II)

• Components are developed manually (or, later, generated) adhering to specific interfaces.

• The container which provides the infrastructure to the components is automatically created,

• Based on a specification of required features

• And the implicit requirements of the components that are configured to run in it.

• With respect to the small components approach, the container is considered the product family, and it is specified, automatically created and assembled using generative techniques.



Useful Features for an embedded container

• Scheduling

• Interrupt Handling

• Storage Service

• Simple Event service

• Generic driver interface

• Pluggable transport

• Security

• Store and forward

• Paging

• ...



Related Technologies

• Jini is a platform for spontaneous networking

• Ninja is a project by the University of Berkeley that defines an architecture for intelligent network-centric services.

• OSGi is a platform to manage services on small devices. Maybe it could be used as a basis.

• WebServices defines an XML over HTTP based RPC mechanisms for use in the internet.

• Apache SF project to build a framework for server apps

• MQ everyplace is a version of the MQSeries messaging middleware that is available for small devices.

• Java could be useful as a platform independent programming language.

• TAO is a well-known and modular ORB that might be useful as a communication backend.



Contents

• Introduction






• The Prototype




Problem Space, Feature Model

• Additional Constraints:• Timer requires Signalling• Interceptors require Proxy• Signalling requires Signal Handling interface

• Defaults:• No passivation

Rem oteAccess

Container

Com ponent

S erviceI nterface

LifecycleI nterface

ResourceI nterface

RMICORBA J MS S ocketsS essionMgm t

Passivation

S ignals T im erS ignalHandling

I nstancePooling

I nter-ceptors

S ecurityLog .. .

Proxy



Problem Space - Configuration

Interceptors

Instances

Component

<ContainerConfig name="TestContainer" package="generated.smc">

<Components>

<Component className="de.mathema.smc.test.PrintTextComponent" id="printerComponent" implementationClass="default">

<Config className="TextPrinter" package="generated.smc" />

</Component>

<Instances>

<SingleInstance asynch="false" id="signallerComponent" role="signaller"> <RuntimeConfig /></SingleInstance>

<SingleInstance asynch="false" id="loggerComponent" role="systemLogger"> <RuntimeConfig /></SingleInstance>

</Instances>

</Components>

<Interceptor className="de.mathema.smc.test.LogMethodCallInterceptor" name="logger" needsParams="true" needsPostinvoke="false">

<Target role="calculator"/>

</Interceptor>

</ContainerConfig>



Generative Approach for the Container

• A system family needs to be created

• We need to create a highly optimized solution, to be useful on the limited embedded devices.

• We have a set of prebuilt components used by the Generator

• We use code generation + parametrization

Solution SpaceConfiguration

Know ledgeProblem Space

Config DataConfig Data

J ava C lassJ ava C lassJ ava C lassJ ava C lassXML File

UserCom ponents

Generator/Composer/

Configurator

ContainerCom ponents

ConfigK now ledge

J ava C lass

Config Data



What does a component look like

• A component has three interfaces

• The Service Interface defines the operation the component offers to its clients

• The Resource Interface specifies the resources the component needs to work correctly

• The Lifecycle Interface is used by the container to manage an instance‘s lifecycle in the container

Com ponentService

I nterface

LifecycleI nterface

ResourceI nterface

client v iew

container v iew



The Service Interface

• The Service Interface is different for each component.

• It defines all the operations the component provides to its clients.

• It uses the suffix SI appended to the component name.

• Example: A Calculator Componentpublic interface CalculatorSI extends Service {

public int add( final int a, final int b ) ;

public int divide( final int a, final int b ) throws java.lang.ArithmeticException;

public int minus( final int a, final int b ) ;

public int times( final int a, final int b ) ;

}



The Resource Interface

• The Resource Interface is different for each component.

• It defines all the resources required by the component.•Service Interfaces of other components

•Any other resources provided by the container

• It uses the suffix RI appended to the component name.

• Example: A Calculator Componentpublic interface CalculatorRI {

public void setPrinter( final TextPrinterSI thePrinter ) ;

public void setSignaller( final SignallerSIBase theSignaller ) ;

}



The Lifecycle Interface

• The Resource Interface is similar for each component.

• It defines how the container handles components

• It is called LifecycleInterface

• Definition of the LifecycleInterfacepublic interface LifecycleInterface {

public void configure( ConfigCtx config );

public boolean configurationComplete();

public List getConfigLogMessages();

public void run();

public void shutdown();

}



Contents

• Introduction






• The Prototype




Challenges in the automotive Domain

• Typical modern vehicles consist of up to 50 Electronic Control Units (ECUs)

• (and of course, some mechanics )

• They run complex, distributed software systems.

• Software System Families can be defined on two levels:

• There are different (software) configurations of a single ECU, because the hardware device they control (engine, brake system, air conditioning) varies.

• There are different configurations of the vehicle itself – the collaboration of the ECUs and the vehicle as a whole can be considered a family



Challenges in the automotive Domain (II)

• Robustness for the system is crucial, well-defined fail-safe modes must be defined (e.g. what happens when the ECU for the brake system crashes?)

• Diagnosability: Diagnosing problems, failures and errors in a vehicle has become a complex and difficult task.

• External diagnosis systems can only work efficiently, if the errors are well described internally by the software in the vehicle. This is really a big issue today!

• Development of new ECU software packages must be very efficient, because the rate at which cars are improved and changed increases.



Some Benefits of in-vehicle components

• Every component has a standardized diagnosis interface.

• This allows component-based diagnosis and

• Hierarchical diagnosis on a component tree

• The component could also provide an interface to provide meta-information about itself and the resources it requires.

• Currently this information is held outside the car in databases, and usually out-of-date.

• A component knows ist container (i.e. a software system running on the hosting ECU) and can query the container for problems



Some Benefits of in-vehicle components

• A component can be migrated to another container (aka ECU) in case of a failure.

• If a vehicle feature should be distributed over several ECUs, a virtual component can be defined to serve as a facade.

• A specific container can also help with diagnosis by e.g. checking timing requirements (a kind of debug mode for the car)

• Studies are currently executed at several OEMs to investigate the feasibility of the approach.



Contents

• Introduction






• The Prototype




The End.

Thanks!Questions?Comments?Criticism?

Markus Völter

[email protected]

www.voelter.de

Documents

Embedded Components CDUF 2002 i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e © 2002 Markus Völter. - 1 - Embedded