Kein Folientitel

1
Embedded Components Component
Infrastructuresfor embedded and small
systems Markus Völtervoelter_at_acm.orgwww.voelter
.de
2
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

3
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

4
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.

5
What is a component infrastructure (II)
6
Component Infrastructures

• System functionality is separated into
  components
• Components are then hosted in a container that
  handles technical concerns for them

7
Component Infrastructures

• A component has a well-defined and separated
  interface.
• Container handles the lifecycle of components

8
Component Infrastructures

• 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).

9
What is a component
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

• 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

10
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

11
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

12
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

13
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

14
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

15
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

16
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.

17
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

18
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.

19
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.

20
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.

21
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

22
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

23
What is a software system family?
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

• A set of programs
• related through their common properties
• And distinguished through their specific
  properties

24
Product Line Engineering

• Domain Scoping
• Variability Analysis
• Domain Structuring
• Define common architecture
• Define Production Plan
• Define Building Blocks
• Components
• DSLs Generators
• Production Process

25
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

26
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...

27
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

28
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

29
Consequences of Binding Times
30
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. Definitio
n by Eisenecker Czarnecki
31
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

32
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 applicationsThis
  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

33
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

34
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.

35
Useful Features for an embedded container

• Scheduling
• Interrupt Handling
• Storage Service
• Simple Event service
• Generic driver interface
• Pluggable transport
• Security
• Store and forward
• Paging
• ...

36
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.

37
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

38
Problem Space, Feature Model

• Additional Constraints
• Timer requires Signalling
• Interceptors require Proxy
• Signalling requires Signal Handling interface
• Defaults
• No passivation

39
Problem Space - Configuration
ltContainerConfig name"TestContainer"
package"generated.smc"gt ltComponentsgt
ltComponent className"de.mathema.smc.test.PrintTex
tComponent" id"printerComponent"
implementationClass"default"gt ltConfig
className"TextPrinter" package"generated.smc"
/gt lt/Componentgt ltInstancesgt
ltSingleInstance asynch"false" id"signallerCompon
ent" role"signaller"gt ltRuntimeConfig
/gtlt/SingleInstancegt ltSingleInstance
asynch"false" id"loggerComponent"
role"systemLogger"gt ltRuntimeConfig
/gtlt/SingleInstancegt lt/Instancesgt
lt/Componentsgt ltInterceptor className"de.mathem
a.smc.test.LogMethodCallInterceptor"
name"logger" needsParams"true"
needsPostinvoke"false"gt ltTarget
role"calculator"/gt lt/Interceptorgt lt/ContainerCo
nfiggt
Component
Instances
Interceptors
40
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

41
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 instances lifecycle in the
  container

42
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 Component

public 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 )

43
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 Component

public interface CalculatorRI public void
setPrinter( final TextPrinterSI thePrinter )
public void setSignaller( final SignallerSIBase
theSignaller )
44
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 LifecycleInterface

public interface LifecycleInterface public
void configure( ConfigCtx config ) public
boolean configurationComplete() public List
getConfigLogMessages() public void
run() public void shutdown()
45
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

46
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

47
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.

48
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

49
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.

50
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

51
The End.

• Thanks!
• Questions?
• Comments?
• Criticism?

• Markus Völter
• voelter_at_acm.org
• www.voelter.de