1

23-04-18

Component-based approach for embedded systems

Ivica CrnkovicMälardalen University (MdH)

Department of Computer Science and Electronics,Mälardalen Real-time Research Centre (MRTC)

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

2

23-04-18

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

Department of Computer Engineering

Real-Time Systems Design Lab Computer Architecture Lab

Computer Science Lab Software Engineering Lab

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

3

23-04-18

Outline

PART I• RESEACH AT MdH

Part II• Basic characteristics of Component-based Software

Engineering• Component-based approach in different domains –

benefits and challenges• Embedded systems – some examples• CBSE for different types of embedded systems –

concerns

4

23-04-18

2

15 000 studenterEskilstuna & Västerås

Drygt 9100 HÅS Ca. 1000 anställda 9 institutioner

– 50 ämnen– 600 fristående kurser – 50-tal utbildningsprogram

ca. 700 miljoner i omslutning ca. 120 miljoner forskning, externt ca

80 miljoner vetenskapsområde teknik ca. 60 professorer inkl. gäst och

adjungerade (15-20) ca 225 doktorander drygt 400 utländska magisterstudenter,

MIMA

Mälardalens Högskola - 2005Mälardalen University

• Placed in Västerås and Eskilstuna

• 16 000 students• 400 intl. magister

students

• Research– 12 M€– 60 professors– 250 PhD students

5

23-04-18

IDE och other MdH-depts

• Engineering– Department of Computer Science and Electronics, IDE – Innovation, Design and Product Development, IDP– Public Technology– Mathematics & Physics, IMa– Biology & Chemistry, IBK

• Humanities, Social sciences and Caring sciences

6

23-04-18

IDE facts and figures

• Staff: ~100– 10 Professors– 20 Researchers/Senior Lecturers– 60 PhD-students (~20 of which are Industrial PhD-students)– 10 Lecturers– 10 Admin+Engineering

• IDE = merge of two depts. in Jan 2005– Computer Science and Engineering (MRTC)– Electrical Engineering (ISS)

• Strong focus on research: > 60%

7

23-04-18

Industrial co-opCommercialisation

of research

Basic andapplied

research

MRTC’s 3 legs

UndergraduateGraduateContinuedEducation

9

23-04-18 6

Medical

Tech.

Architecture forRT-System

IndustrialSoftware-eng

Software forembeddedsystem

RT-Design

DebugTest

RT-Flex

Data-comm

RF- -Tech.

Robotics

Comp.Scitheory

Real time

Software-

Meka-tronic

MRTC & ISS activities

VolvoS80

Program Beräkning

Flöes -analys

Maskinvaru-analys

MedicalTech.

AI Program-analysis

Groups

IDE

Lab

ISS

MRTC

10

23-04-18

Senseboard

ABB Automation

WestinghouseVTEC

Volvo CEC

Bombardier

Volvo PV

ABB RoboticsRealFast

CC-SystemsEricsson Microwave

ZealcoreArcticus

ÅF

Ericsson Core NetworkVolcano CTPBM StressMedicin

40+ companies~20 Industrial PHD STUDENTS

Industrial cooperation

ArdendoComet

ABB Research

MRTC cooperations

KTH (M.Törngren)

LiTH (S.Nadjm-Tehrani)

UU (B.Jonsson, P.Gunningberg, W.Yi)

SICS (B.Ahlgren,B.Levin)

LTH (K-E.Årzén, P.Runesson)

ARTES/CUGS/ASTEC/SAVE/Flexcon

National research cooperation EU NoE ARTISTPhilips Research (L.Steffens, R.v.Ommering)

U. Cantabria (M.G.Harbour) L’Aqualia University (Paola

Inverardi)

U. York (Alan Burns, …)

U. Tampere (P. Abrahamsson)

SEI/CMU (K.Wallnau)

MIT (K.Lundqvist)

U. Aveiro (L.Almeida)

TU Darmstadt (N.Suri)Manchester U (Kung-Kiu Lau)

UPC Barcelona (J.Fuertes)

C-Lab (F.Stappert)

U.Catania (L.LoBello)

TU Eindhoven (M.Chaudron)

SSSA Pisa (G.Buttazzo)

TU Porto (E. Tovar)

U.Zagreb (M.Zagar)

TU Wien (H.Kopetz,P.Puschner)

UC Irvine (K.J.Lin)

Microsoft Research (Clemens Szyperski)TUFTS U., Boston (Judith Stafford)

Georgia Tech.(V.Mooney)

UT Austin (A.Mok)

U.Virginia (J.Stankovic)

IIT Bombay (K.Ramamritham)

Seoul Nat’l U (S.Lyul Min)

Monash U (H.Schmidt)U.New South Wales (J.Xue)

Int’l research cooperation

U.Rio Grande (C.Pereira)

RTmetoder &

verktyg

Flexiblaplattformar

Komponent-baseradpgmvara

PROGRESSBTH (C.Wohlin)

11

23-04-18

Model of cooperation with industry

studentsstudents

Phd students

Phd students

ResearchersResearchers

Theses & interns

Industry stays

Research stays

Eval. of research results

Courses

Meetings &seminars

Coordinationgroup

IndustrialPhD-students

Research-projects

Bombardier Transportation

12

23-04-18

Reseach at Mälardalen University (MdH)

Component-based approach for embedded systems

Ivica CrnkovicMälardalen University (MdH)

Department of Computer Science and Electronics,Mälardalen Real-time Research Centre (MRTC)

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

13

23-04-18

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/

14

23-04-18

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• Process issues, organizational and management issues,

technologies (for example component models), theories (component compositions), tools…

15

23-04-18

Why component-based approach?• Advantages from the 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 reusability, interoperability, flexibility, adaptability,

dependability…

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

• CB-approach has been successful in many application domains:– Web- and internet-based applications– Desktop and office applications, Graphical tools, GUI-based

applications– In certain segments of telecommunication, consumer electronics…

16

23-04-18

CBSE – basic definitions• The basis is the Component• Components can be assembled

according to the rules specified by the component model

• Components are assembled through their interfaces

• A Component Composition is the process of assembling components to form an assembly, a larger component or an application

• Component are performing in the context of a component framework

• A component technology is a concrete implementation of a component model

c1 c2

Middleware

Run-time system

framework

Component Model

17

23-04-18

Component Technology

Component Component Framework

Platfo

rmP

latform

Co

mp

on

ents

Co

mp

on

ents

RepositoryRepository

Supporting ToolSupporting Tool

18

23-04-18

Implications of the CBSE approach

• 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

• A combination of a bottom-up and top-down approach• Many explicit and implicit assumptions

– Architectural styles (middleware, deployment,..)

19

23-04-18

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.

20

23-04-18

Another definition

• A software component is a software element that – confirms a component model – can be independently deployed – composed without modification according to a composition

standard.

• A component model defines specific interaction and composition standards.

G. Heineman, W. Councel, Component-based software engineering, putting the peaces together, Addoson Wesley, 2001

21

23-04-18

Implications of Szyperski’s Definition

• The following implications arise as a result of Szyperski’s definition:

– For a component to be deployed independently, a clear distinction from its environment and other components is required.

– A component must have clearly specified interfaces.

– The implementation must be encapsulated in the component and is not directly reachable from the environment.

(Black box nature)

22

23-04-18

Component specification

• Components are described by their interfaces

• (A black box character)

glass boxglass box

black boxblack box

white boxwhite box

grey boxgray box

23

23-04-18

Components and Interfaces - UML definition

Component

Interface

Operation

*

in-interfaces*

*

*

Name

1

1

1 1

1

1

Parameter

1

*

Type

1 *

OutParameterInParameter

InOutParameter

*

out-interfaces

*

Component – a set of interfacesrequired (in-interfaces)provided (out-interfaces)

Interface – set of operationsOperations – input and output parameters of

certain type

24

23-04-18

IDL Exampleinterface ISpellCheck : IUnknown{

HRESULT check([in] BSTR *word, [out] bool *correct);}; interface ICustomSpellCheck : IUnknown{

HRESULT add([in] BSTR *word);HRESULT remove([in] BSTR *word);

}; library SpellCheckerLib{

coclass SpellChecker{

[default] interface ISpellCheck;interface ICustomSpellCheck;

};};

25

23-04-18

Contractually specified interfaces

• Extension of Interface (adding contract)– a set of interfaces that each consists of a set of operations.

– a set of preconditions and postconditions is associated with each operation.

– A set of invariants

• Also called: Contractually specified interfaces

26

23-04-18

Precondition, Postconditions, Invariants• Precondition

– an assertion that the component assumes to be fulfilled before an operation is invoked.

– Will in general be a predicate over the operation’s input parameters and this state

• Postcondition– An assertion that the component guarantees will hold just after an operation

has been invoked, provided the operation’s pre-conditions were true when it was invoked.

– Is a predicate over both input and output parameters as well as the state just before the invocation and just after

• Invariant– Is a predicate over the interface’s state model that will always hold

27

23-04-18

Semantic Specification in a UML metamodel

Interface

Component

*

in-interfaces*

*

out-interfaces

*

State

1 *

Constraint

*

*

* 1

Invariant

1

*

1

*

Operation

*

*

Parameter

1

*

PreCondition

* 1

PostCondition

1 *

1

*

InParameter OutParameter

*

*

*

*

*

*

*

2

29

23-04-18

Extrafunctional properties

• Extrafunctional (non-functional) properties– runt-time properties

• Performance, latency• Dependability (Reliability, robustness, safety)

– Lifecycle properties• Maintainability, usability, portability, testability,….

• There is no standards for specification of extrafunctional properties

30

23-04-18

Extrafunctional properties specifications Credentials (Mary Shaw)

• A Credential is a triple <Attribute, Value, Credibility>– Attribute: is a description of a property of a component– Value: is a measure of that property– Credibility: is a description of how the measure has been obtained

• Attributes in .NET – A component developer can associate attribute values with a component

and define new attributes by sub-classing an existing attribute class.

• ADL UniCon – allows association of <Attribute, Value> to components

31

23-04-18

Extra-functional PropertiesComponent

Interface

Operation

*

in-interfaces*

*

*

AttributeValueCredibilityIsPostulate : Boolean

Credential

*

1

* 1

*

1

Parameter

1

*

Type

1 *

*

out-interfaces

*

32

23-04-18

Main principles of CBSE: (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

33

23-04-18

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

34

23-04-18

Substitution

• Substituting a component Y for a component X is said to be safe if:– All systems that work with X will also work with Y

• From a syntactic viewpoint, a component can safely be replaced if:– The new component implements at least the same interfaces as the

older components

• From semantic point of view?– Contractual interface holds (pre-, postconditions and invariants)

35

23-04-18

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

36

23-04-18

Main principles: (4) Composability• Composition of components

– P(c1 o c2) =P1(c1) o P2(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

C

37

23-04-18

Components for Embedded Systems

38

23-04-18

Do existing component technologies meet the requirements of different domains?

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

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

– Do not consider a number of extra-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?

39

23-04-18

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,8% of computer systemsare embedded systems (DARPA 2000)

40

23-04-18

Characteristics of ES: Interaction with the environment

A sensor transforms physical data (temperature, pressure) to digital format

Examples: thermometer, microphone, video camera

• An actuator works the other way round - transforming digital data to physical format.

Example: motors, pumps, machines…

An embedded system interacts with the environment via sensors and actuators

RTsoftwaresystem

Sensor

ActuatorProcess

41

23-04-18

RT Systems : Correct result at the right time

Example:

An air bag must not be inflated too late, not too early!

In some cases the system must wait before it responds!

Collision

Too late

time

Too early

ES – Real-time systems

42

23-04-18

Real-time in Football - Offside rules

43

23-04-18

Too late

44

23-04-18

Too eraly

45

23-04-18

Most of the real-time systems are based on following:

1. Several parallel activities are given some unique priorities2. A resource manager makes sure the task with the highest

priority will execute

Challenges when constructing RT ES

1 3

Activities

Resource manager

timeCPU

1

2

3

ready

ready

Processing requires resources (time, CPU-time, memory,..)

46

23-04-18

Enough resources– You can always guarantee that all functions in the system are able

to execute when they so desire.

– Most often safety critical applications

– Expensive

– Example: ABS-system, ”fly-by-wire”-system, power plant…

Limited resources– There may be occasions when the system is unable to handle all

functions that wants to execute.

– Designed to work well under normal conditions.

– Example: telephone – everybody wants to make a phone call simultaneously will result in that some has to wait.

Enough resources vs. Limited resources

47

23-04-18

Event driven real-time systems– External events determines when a program is to be

executed

– Often through interrupts

– Example: telephone switches, ”video-on-demand”, transaction systems…

Time driven real-time systems– The system handles external events at predefined points

in time

– Most often cyclic systems repeats a certain scenario

– Example: ABS, control systems, manufacturing systems…

Event driven vs. time driven systems

48

23-04-18

Hard real-time systems– The cost for not fulfilling the functional and temporal constraints are

severe

– Failing to meet hard real-time constraints results in computations, at best, being useless

– Often safety critical the correctness must be verified before system operation

– Example: ABS, airbag, defence system, power plant…

Soft real-time systems– Occasional miss of fulfilling a timing constraint can be acceptable

– The usefulness of the computation is reduced (reduced service) Example: reservation systems, ATM machines, multimedia, virtual reality…

Hard vs. Soft real-time systems

49

23-04-18

• New requirements (RT requirements) introduce new challenges in achieving the CBSE principles

• Example:– Substitution principle for RT components.

50

23-04-18

Substitution principles• When we can replace a component?• Goal: on-line upgrade task components in a ‘safe’ way

• Two issues:– new components must not be faulty– schedulability of all tasks (components) must be guaranteed

• Run-time upgrade possible if worst case execution time– WCET (new comp) ≤ WCET (old comp)

• Is that correct?

51

23-04-18

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 Fast priority scheduling

task priority

A high

B medium

C low

Rel = release time

dl = deadline

52

23-04-18

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)

59

23-04-18

Some examples of component models

60

23-04-18

The Koala Component Model – Philips CE

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

61

23-04-18

Property

keyvalue

PropertyBundle

name

Port

typeDirectionrange

Connector

typeComponent

name

scheduling

memory

Sub-components

Eventcomponent

Activecomponent

passivecomponent

event info

thread info

Pecos component model (ABB)

62

23-04-18

SaveCOM – component model for embedded system developed at MdH

• Target systems - Safety Critical Embedded Real-Time Systems– Reliability

– Timeliness

– Resources (memory, CPU)

– Safety

• Key features addressed– Efficient development

– Predictable system behavior

– Low foot print

63

23-04-18

ComponentDevelopment

System Configuration

Run-timeEnvironment

ComponentSpecification

Operational/constructiveInterface

AnalyticInterface

SystemArchitecture

Verification Technology

Verification

DevelopmentProcess

SaveComp Framework developed at MdH

SaveComp TechnologySaveCom Component Model

IDE-systemconfiguration

Verification &compositionTechnology

ComponentComposition

64

23-04-18

Static Configuration (Off-line)

<<Switch>>

S1

<<SaveComp>>

PC

<<SaveComp>>

IC

<<SaveComp>>

DC

<<Switch>>

S2

<<SaveComp>>

Compose

Set Actual

P I D

Control

<<Assembly>>

PID

P-Mode

1 0 0

<<SaveComp>>

PC

<<SaveComp>>

Compose

<<Assembly>>

P

Set ActualControl

65

23-04-18

SaveCom Framework

66

23-04-18

Conclusion & Summary

• There is a visible trend in acquiring CB approach in development of embedded systems

• New component technologoes and utilization of the existing theories important.