component-based approach for embedded...

1

2004-11-29

Component-based approach for embedded systems

Ivica CrnkovicMälardalen University

Department of Computer Science and Engineering,Mälardalen Real-time Research Centre

Swedenhttp://www.idt.mdh.se/~icc

2

2004-11-29

Mälardalen University (MdH)Mälardalen University, Vasteras (Västerås)

Department of Computer EngineeringReal-Time Systems Design Lab Computer Architecture LabComputer Science LabSoftware Engineering Lab

Prof. in Software Engineering http://www.idt.mdh.se/~iccivica.crnkovic@mdh.se

3

2004-11-29

Outline• Basic characteristics of Component-based Software

Engineering• Component-based approach in different domains –

benefits and challenges• Embedded systems – some examples• Different types of embedded systems – concerns• Component models for embedded systems (examples) • Needs and challenges, research directions

4

2004-11-29

Sources of information

SAVESAVE

http://www.cbsenet.org/pls/CBSEnet/ecolnet.home

http://www-artist.imag.fr/Overview/

http://www.mrtc.mdh.se/SAVE/

Ivica Crnkovic and Magnus Larsson:

Building Reliable Component-Based Software Systems

Artech House Publishers, 2002, ISBN 1-58053-327-2

http://www.idt.mdh.se/cbse-book/

5

2004-11-29

Component-based approach• Building systems from (existing) components

– Providing support for the development of systems as assemblies of components

– Supporting the development of components as reusable units– Facilitating the maintenance and evolution of systems by customizing

and replacing their components• Component-based Software Engineering

– Provides methods and tools supporting different aspects of component-based approach

application

Component#1

Component#2

Component#3

Component#4

Component

#1

Component

#2

Component

#3

Component

#4

6

2004-11-29

Implications• Component development is separated from system

development process– Less programming efforts to build systems– System verification and validation more difficult and more

important– Different requirements management

Requirements

Specification

Design

Implementation

TestDeploy

Find & Select

Adapt

Test

Applicationdevelopment

Componentdevelopment

Operation &Maintenance

7

2004-11-29

CBSE process issues

• Different types of approaches– Using components as well defined design units– Product-line approach

• Building many variants and versions of a products based on the same architecture and varying components. Components are developed in-house

– COTS (Commercial off the shelf) components• Building systems from existing components

8

2004-11-29

Main principles: (1) Reusability• Reusing components in

different systems

• The desire to reuse a component poses few technical constraints.

• Good documentation (component specification…)

• a well-organized reuse process

• Similar architecture• ….

C1

C1 C2

C3 C4

Application A1

C1 C5

C6 C7

Application A2

9

2004-11-29

Main principles: (2) Substitutability• Alternative implementations of

a component may be used.

• The system should meet its requirements irrespective of which component is used.

• Substitution principles– Function level– Non-functional level

• Added technical challenges– Design-time: precise definition

of interfaces & specification– Run-time: replacement

mechanism

C1 C2

C3 C4

Application A1

C1´ C2

C3 C4

Application A1

10

2004-11-29

Substitution principles• When we can replace a component?• Functional properties

– Substitution OK if it accepts wider range of input and provides smaller range of output

• What about Real-time properties?– new components must not be faulty– schedulability of all tasks must be guaranteed

• Existing approach – Sha 1998– basic idea: monitor output to ensure values within valid range– run-time upgrade possible if

WCET (new comp) ≤ WCET (old comp)

– Is that correct?

11

2004-11-29

A B C

rel(A,C) rel(B) dl(B) dl(A,C)

(a)

B CC

A is replaced by A’; wcet(A’)<wcet(A)

Order of execution changed – deadline met

A’

rel(A,C) rel(B) dl(B) dl(A,C)

(b)

Example 1: preemptive FPStask priority

A high

B medium

C low

12

2004-11-29

Example 2: non-preemptive FPS

A B C

rel(A,C) rel(B) dl(B) dl(A,C)

BC

dl(A,C)

B misses deadline!

(a)

A’

rel(A,C) rel(B) dll(B)

(b)

task priority

A high

B medium

C low

A is replaced by A’; wcet(A’)<wcet(A)

13

2004-11-29

Main principles: (3) Extensibility

• Comes in two flavors: – extending components that are part

of a system– Increase the functionality of

individual components

• Added technical challenges:– Design-time: extensible architecture– Run-time: mechanism for

discovering new functionality

C1 C2 C3

C1 C2+ C3

C1 C2 C3

C1 C2 C4 C3

14

2004-11-29

Main principles: (4) composability• Composition of components

– F(c1 o c2) =F1(c1) o F2(c2)

– Composition of functions– Composition of extra-functional

properties

• Many challenges– How to reason about a system

composed from components?• Different type of properties• Different principles of compositions

C1 C2

assembly

Example:Pipe & filter:F(c1 o c2)(x)= F1(F2(x))

15

2004-11-29

Software Component Definition

Szyperski (Component Software beyond OO programming)• A software component is

– a unit of composition – with contractually specified interfaces – and explicit context dependencies only.

• A software component – can be deployed independently – it is subject to composition by third party.

16

2004-11-29

Describing a Component

• To be able to describe a component completely the component should consist of the following elements:

– A set of interfaces provided to, or required from the environment.– An executable code, which can be coupled to the code of other

components via interfaces.• How to specify a component?

black boxblack box white boxwhite box glass boxglass boxgrey boxgrey box

17

2004-11-29

Interface specification

• Construction interface (Operations)• Pre-, post-conditions and invariants• Specification of extra-functional properties

– Run-time properties• Performance, latency• Dependability (Reliability, robustness, safety)

– Life cycle properties• Maintainability, usability, portability, testability,….

18

2004-11-29

Experience in use of component technologies

• Many successes– Office applications– Graphical/desktop applications – Information systems– Distributed applications (web-based)– Particular domains (GIS), Telecommunication, consumer

electronics,…

• Several component technologies widely used– Ms COM/DCOM– Ms .NET– Sun EJB, J2SEE– OMG CORBA, Corba CM

19

2004-11-29

How much is CBSE attractive for different domains?

• Advantages from a business point of view:– Shorter time-to-market, lower development and maintenance

costs

• Advantages from technical and engineering point of view

– Increased understability of (complex) systems– Increased the usability, interoperability, flexibility, adaptability,

dependability…

• Advantages from strategic point of view of a society – Increasing software market, generation of new companies

20

2004-11-29

Do existing component technologies meet the requirements of different domains?

• Widely-used component models (Microsoft COM/DCOM and .NET, Sun EJB,J2SEE, OMG Corba CM,…)

– Focus on functionality, flexibility, run-time adaptability, simpler development and maintenance

– Do not consider non-functional requirements• Timing properties (performance), resource consumptions• Reliability, availability, quality of services…

Important questions for CBSE feasibility:• Which are the primary requirements in different domains? • Can CBSE provide solutions that meet these requirements?

21

2004-11-29

What are embedded systems?

An Embedded Computer System: A computer system that is part of a larger system and performs some of the requirements of that system. (IEEE, 1992).

99,99% of computer systemsare embedded systems (DARPA 2000)

22

2004-11-29

Embedded(how many computers do you see?)

23

2004-11-29

Example: The architecture of a car control system

Vehicle mechanics

ECU

Sensor ActuatorSensor

ECU

Sensor ActuatorSensor

ECU

Sensor ActuatorSensor

gateway(CAN) BUS

brake injection

Infotaiment

ECU – Electronic Control Unit

24

2004-11-29

sensors

Challenge – open and dependable platform

Vehicle

actuators

Engine Control Local brake Control Transmission ……… local

Vehicle stability

Cruise control Antispin Global

(complex) functions

Hardware

Input/output drivers

MiddlewareECU ECU ECU

Applications

SOFTWARE COMPONENTS

Collision detection

25

2004-11-29

Specific requirements of embedded systems

• Real-time requirements• Resource consumption

– CPU, Memory, Power, Physical space• Dependability

– Safety, reliability, availability• Life-cycle properties (long life systems)

– Maintainability, expandability– Portability

• Increasing interoperability

26

2004-11-29

Basic concepts for Component-based Embedded Systems

• Main concern– Predictability of different properties (on

account of flexibility)

• Difference between small and largeembedded systems

27

2004-11-29

Component models for small embedded systems vs. General-purpose component models

Small Embedded Systems• Composition time separated form

run-time• Optimization at configuration time

(direct references, unneeded functionality removed)

• Explicit context dependencies• Run-time environment (CPU,

RTOS, resource constraints)

• Fine-grained

• Reuse & portability• white, glass, or grey box

components• source code portability

General-purpose components• Run-time composition (late

binding) • Set of interfaces, “bugs” of

services

• Contractual-based interfaces• Not resource-usage aware

• Coarse-grained

• Portability - Binary independence (Black-box reuse)

28

2004-11-29

Component-based approach for LARGEembedded systems

• the resource constraints are not the primary concerns.

• The complexity and interoperability important • Minimizing the development costs

• For this reason general-purpose component technologies are of more interest than in a case for small systems.

29

2004-11-29

Widely-used component models and embedded systems

• Direct use of component models– CORBA (telecommunication)– COM/DCOM, .NET – process industry

• Improved component-models (with added functionalities)– OPC (OLE process control Foundation)

• Restricted (use of) component-models to achieve predictability– Using only specification (IDL) , no multiple interface, etc.

30

2004-11-29

OPC (OLE for Process Control)• industry standard for communication between

components in field devices, automation equipment and business applications (generic driver)

• data model• set of interfaces for COM

– server interfaces– callback interfaces

• managed by OPC Foundation (www.opcfoundation.org)

31

2004-11-29

OPC: How does OPC Solve the Problem?

SoftwareDriver

SoftwareDriver

SoftwareDriver

SoftwareDriver

OPC OPC OPC OPC

DisplayApplication

TrendApplication

ReportApplication

OPC OPC OPC

32

2004-11-29

Some examples of componentmodels for embedded systems

33

2004-11-29

Thanks to Rob van Ommering Philips ResearchEindhoven, The Netherlands

KOALA COMPONENT MODEL

34

2004-11-29

The Koala Component Model

CC

C2

C1

C3

Koala is:- a Software Component Model- with an ADL- to build populations of

resource constrained products

Koala is:- a Software Component Model- with an ADL- to build populations of

resource constrained products

35

2004-11-29

PECOS Component Model - ABB (Pervasive Component Systems)

Device Builder

Component Library• function blocks• asset management• parameter storage• display

Component Library• function blocks• asset management• parameter storage• display

Composition Environment

• composition development• code generation for run-

time• check component

compatibility

Composition Environment

• composition development• code generation for run-

time• check component

compatibility

Run-time Environmentoptimized, ultra-light run-timeexperimental Java-based run-time

Run-time Environmentoptimized, ultra-light run-timeexperimental Java-based run-time

36

2004-11-29

Property

keyvalue

PropertyBundle

name

Port

typeDirectionrange

Connector

typeComponent

name

scheduling

memory

Sub-components

Eventcomponent

Activecomponent

passivecomponent

event info

thread info

Pecos component model

37

2004-11-29

Example - Adoption of a general-purpose component model

ABB Controller - Componentization of a system• Requirements

– Improve the development process• Distributed development• Shorter time-to-market Redefined architecture

• Conditions:– Keep the main requirements (real-time) unchanged

• Solution– Componentize the software architecture– Use of a subset of a component model (COM)

38

2004-11-29

Use of the Component Object Model (COM)

• COM is a public specification (by Microsoft) which emphasizes separation of interfaces and implementation

• A well-defined subset of the COM specification has been adopted • COM compliant interfaces can be used on platforms without COM

run-time support• On platforms with COM run-time support:

– Protocol handlers implemented as COM classes• On platforms without COM run-time support:

– Protocol handlers implemented as C++ classes, which must be statically linked with the framework

39

2004-11-29

Conclusion: What are the needs?

• Need for component models and frameworks for embedded systems. – the run-time platform must provide certain services, which however

must use only limited resources.• Obtaining extra-functional properties of components in

particular timing and performance properties. • Component certification• Platform and vendor independence • Component noninterference applications, (in terms of

memory protection, resource usage, etc).• Tool support: The adoption of component technology

depends on the development of tool support.

40

2004-11-29

References• Conferences and Workshops

– Component-based Software engineering Symposium:• http://www.sei.cmu.edu/pacc/CBSE7/• http://www.sei.cmu.edu/pacc/CBSE8/

– Euromicro conference, CBSE track• http://www.idt.mdh.se/ecbse/2004/• http://www.idt.mdh.se/ecbse/2005/

– WCOP International Workshop on Component-Oriented Programming• http://research.microsoft.com/~cszypers/events/wcop2004

– International Working Conference on Component Deployment• http://cd04.cs.ucl.ac.uk/

– Workshop on Component Composition