1

04/18/23

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

04/18/23

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

04/18/23

Outline

• 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

04/18/23

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

04/18/23

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…

6

04/18/23

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…

7

04/18/23

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

8

04/18/23

Component Technology

Component Component Framework

Platfo

rmP

latform

Co

mp

on

ents

Co

mp

on

ents

RepositoryRepository

Supporting ToolSupporting Tool

9

04/18/23

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

10

04/18/23

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.

11

04/18/23

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

12

04/18/23

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)

13

04/18/23

Component specification

• Components are described by their interfaces

• (A black box character)

glass boxglass box

black boxblack box

white boxwhite box

grey boxgray box

14

04/18/23

Components and Interfaces - UML definitionComponent

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

15

04/18/23

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;

};};

16

04/18/23

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

17

04/18/23

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

18

04/18/23

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

20

04/18/23

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

21

04/18/23

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

22

04/18/23

Extra-functional PropertiesComponent

Interface

Operation

*

in-interfaces*

*

*

AttributeValueCredibilityIsPostulate : Boolean

Credential

*

1

* 1

*

1

Parameter

1

*

Type

1 *

*

out-interfaces

*

23

04/18/23

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

24

04/18/23

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

25

04/18/23

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)

26

04/18/23

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

27

04/18/23

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

28

04/18/23

Components for Embedded Systems

29

04/18/23

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?

30

04/18/23

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)

31

04/18/23

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

32

04/18/23

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

33

04/18/23

Real-time in Football - Offside rules

34

04/18/23

Too late

35

04/18/23

Too eraly

36

04/18/23

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

37

04/18/23

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

38

04/18/23

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

39

04/18/23

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

40

04/18/23

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

• Example:– Substitution principle for RT components.

41

04/18/23

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?

42

04/18/23

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

43

04/18/23

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)

44

04/18/23

Example of an embedded system: 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

45

04/18/23

The architectural design challenge

Vehicle stability Suspension Drive by wire …… Complex functions

Local Control Functions

Sensor ActuatorSensor

Basic functionsLocal Control Functions

Sensor ActuatorSensor

How to implement complex functions based on local control functions?

46

04/18/23

Problem: resource sharing

Sensor 1

Sensor 2

Sensor 3

Sensor ..

Networkresources

++++++++++

++++++++++

++++++++++Sensor ..

Executionresources

Node 1

Node 2

Node 3

Node …

Node …

Actuator 1

Actuator 2

Actuator 3

Actuator …

Actuator …

Can functions of different criticality be allowed to share resources?

47

04/18/23

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

48

04/18/23

Challenge – open and dependable platform

Hardware

Input/output drivers

Middleware

ECU ECUECU

Applications C1 C2

RequirementsSeparation of hw from SW developmentSeparation of SW component development

49

04/18/23

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

50

04/18/23

Basic concepts for Component-based Embedded Systems

• Main concern– Predictability of different properties (on account of

flexibility)

• Difference between small and large embedded systems

51

04/18/23

Unit of composition and independent deployment

• Run-time composition– Component lifecycle,– Run-time environment,– Dynamic composition (late binding)

• Configuration composition– Capable of generating monolithic firmware from

component-based design,– Optimization

• Re-configuration of the components• Direct references

More feasible for embedded systems

Component technology

52

04/18/23

Explicit context dependencies

• Other components and interfaces– required & provided interfaces– (Contractual-based interfaces)

• Run-time environment– CPU,– RTOS,– Resource constraints– Component implementation

language

Embedded systems specific

Component technology

53

04/18/23

Component granularity

• Coarse-grained components– “Bags” with many (partially unused)

functions– Not resource-usage aware– Often distributed components

• Fine-grained components– unneeded functionality removed,

– Scarcer uses of resourcesMore feasible for embedded systems

Component technology

54

04/18/23

Framework

Component Repository

Composition environment

Run-time environment

55

04/18/23

The day after tomorrow…

– Requirements on flexible upgrading • Part of a system• Updating software components• Separation of software from hardware

Binary standards will become important

56

04/18/23

• In most cases the general-purpose component models will not be appropriate for embedded systems

• However other component-based approach is appealing !

57

04/18/23

Component-based approach for LARGE embedded 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.

58

04/18/23

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.

70

04/18/23

Some examples of component models

71

04/18/23

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

72

04/18/23

Property

keyvalue

PropertyBundle

name

Port

typeDirectionrange

Connector

typeComponent

name

scheduling

memory

Sub-components

Eventcomponent

Activecomponent

passivecomponent

event info

thread info

Pecos component model (ABB)

73

04/18/23

SaveComp Model - MdH

Task Allocation

Win 32

APPLICATION

SaveCCM

XML - representation

Design-Time

Compile-Time

Run-Time

<<SaveComp>>

PC

<<SaveComp>>

Compose

<<Assembly>>

P

Set ActualControl

AttributeAssignment

Code Generation & Analysis

C-compiler

RTXC

APPLICATION

Simulation Target

74

04/18/23

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.