November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluating Quality Properties of Component-based Software Architectures Egor BondarevMichel

November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With

Evaluating Quality Properties of Component-based Software Architectures

Egor Bondarev Michel Chaudron

System Architecture & Networking Group

Peter de With (TUE & LogicaCMG)

Video Coding & Architectures Group

Technische Universiteit Eindhoven, The Netherlands


Outline Introduction & Context Problem statement Approach

• scenario-based predictable assembly

Conclusion


Context Robocop/Space4U projects

• high volume embedded systems• mobile phones (Nokia), DVD players (Philips)• multimedia processing and control systems

Open component-based framework for resource constrained systems• Open at run-time: software components may come and go • Requirements: Robustness, Upgrading/extension, and Trading


Problem Statements

(2) How can we ensure that a system will continue to provide the XFQs while third-party software components are added and removed?

(1) Can we design a system using third-party software components that provides the required extra-functional quality (XFQ) properties?

designtime

runtime

Third party software components are black-box i.e. no access to internals/code.

For reasons of efficiency of reuse or protection of IP


Does the system (continue to) behave properly?• Can the system execute tasks in a timely manner?

• Is there sufficient CPU power?

• Does the system have sufficient memory for the tasks?• Is there no malicious use of resources?

Typical system quality attributes:• Performance (timeliness, throughput)• Resource use (processor, memory, bus)• Reliability• Cost

Required eXtra-Functional Qualities


Predictable AssemblyCan we predict the quality attributes of a system based on the properties of its components?

Candidate Quality Properties: Efficiency, Footprint, Responsiveness, Scalability,

Schedulability, Timeliness, CPU utilization, Latency, Throughput, Concurrency, Accuracy,

Accountability, Testability, Traceability, Analyzability, Distributeability, Availability,

Confidentiality, Integrity, Reliability, Safety, Security, Affordability, Extensibility, Tailorability

What do we need to specify per component in order to be able to predict system properties?


Problem Instance: Cost

Derive cost of a system from cost of its parts.

C1

C2 17C1 C2

S2542

More complicated: real-time / timeliness properties

Other example: static memory use


Problem Instance: Timeliness

Derive timing of a system from timing of its parts.

C1

C2 17 secC1 C2

S25 sec?

• way of connecting components (seq, parallel)• shared resources (and their scheduling)• synchronization

It depends …


Characteristics of Target Systems Systems may be event-triggered and time-triggered SW components may be active or passive System support multi-threaded applications System supports dynamic resource (CPU, memory)

allocation There may be dependencies between tasks

• control- and data-dependencies

• synchronization constraints:• task precedence, rendezvous, mutexed operations

System are designed by composing ‘black box’ software- and hardware-components


Requirements on the analysis method

Method should allow • low modelling effort• a trade-off between modeling effort and accuracy• resource-efficient analysis (for run-time analysis)

Nice to have: compatibility with • Unified Modelling Language (UML (2.0))

• IEEE Stnd. 1471 Recommended Practice for Architectural Description of Software-Intensive Systems


Solution Approach

1. Models for both software- and hardware components.

2. Scenarios-based evaluation• The designer can focus on critical aspects of system behaviour.

3. Simulation of scenarios

Based on the following concepts


Proposed Solution

1. Software component models and hardware component models are available at system design time.

2. Resource usage (execution time, bus load) of each component operation is defined by a model.

3. The architect is able to identify a set of critical execution scenarios for an architecture.

Major assumptions:


Example Problem: Car Navigation System (CNS)

MMI

NAV

RAD

MapDB

MMI = Man-Machine Interface

RAD = Radio controller

NAV = Navigation Software

Logical ViewEnvironment


CNS: Architectural Alternatives

Optimal alternatives in terms of:Resource usage + Performance + Reliability + Cost + …

22 MIPS

MMI_Inst

113 MIPS 11 MIPS

72 kbps

(A)

NAV_Inst RAD_Inst

22 MIPS

MMI_Inst

113 MIPS 11 MIPS

72 kbps(B)

NAV_Inst RAD_Inst

57 kbps

22 MIPS

MMI_Inst

260 MIPS

72 kbps

(C)

NAV_Inst

RAD_Inst

130 MIPS

MMI_Inst113 MIPS

72 kbps

(D)

NAV_Inst

RAD_Inst

260 MIPS

MMI_Inst

RAD_Inst

NAV_Inst(E)


Robocop Component Model A Component is a set of models

• Provided by the supplier

Robocop Component

Reliability Model

Functional Model

Behaviour Model

Resource Model

Source Code

Executable Model

Model relations

Service1 Service2

Robocop Component

Provides interface Requires interfaceOperation

ServiceA ServiceB

• Executable Components have Services

• Services have provides and requires interfaces

• Interfaces have operations


Component behaviour model

service c2

requires I2

requires I3

provides I1{

operation f

uses I2.g

uses I3.h

behaviour

operation f calls:

I2.g*

I3.h

}

Behaviour is modeled per operation

Variable & data-dependentcall sequences can be modelled

Service is run-time unit of structuring

?

Behaviour forms a partial call graph

I2c2


Resource ModelResourceModel_MPEG4Decoder_Component

resource use

operation decodeFrame()

cpu claim

max = 1E7 cycles

aver = 1E5 cycles

min = 1E4 cycles

mem claim = 10 KB

mem release = 3 KB

ResourceModel_MPEG4Decoder_Component

resource use

operation decodeFrame()

cpu claim

max = 1E7 cycles

aver = 1E5 cycles

min = 1E4 cycles

mem claim = 10 KB

mem release = 3 KB

Different resource models may be supplied fordifferent (classes) of processors (RISC, VLIW, …)


Model Assembly Phase 0: Define Scenarios

A scenario is a setting of • A set of one or more triggers• A specific configuration of a system

Trigger t fires every s msec

• this trigger starts operation ‘f’ of interface I


g

Model Assembly Phase 1: Structure

A call to operation ‘f’ is startedf

h

j

f is provided by s1

s1 needs g from I2 and h from I3• I2 (hence g) is provided by s2

• s2 is done

• I3 (hence h) is provided by s3

s3 needs j from I4• I4 (hence j) is provided by s4

• s4 is done

s1

s2 s3

s4

At bind-time, the decision is made which services are composed to provide the implementation of an interface


Combine the behaviour models of the operations used

g

Model Assembly Phase 2: Logical Behaviour

Press button ‘f’f

h

j

s1

s2 s3

s4

s1

g g

s2s3

h

s4

j

h

j

operation f calls:S2.g; S2.g; S3.h; S3.h


g

Model Assembly Phase 3: Integrate Resource Claims

f

h

j

s1

s2 s3

s4

s1

g g

s2s3

h

s4

j

(cl,rl) (cl,rl)

(cl,rl)

(cl,rl)

h

j

(cl,rl)

(cl,rl)


Model Assembly Phase 4: Define concurrency behaviour

s1

g g

s2s3

h

s4

j

(cl,rl)(cl,rl)

(cl,rl)

(cl,rl)

h

j

(cl,rl)

(cl,rl)

T1

p

T2T3

q

T4

r

(cl,rl)

(cl,rl)

(cl,rl)

U1

v v

U2

U3

w

(cl,rl) (cl,rl)

(cl,rl)

w(cl,rl)

Mapping of Logical behaviour onto Tasksx y z


Phase 5: Resource Schedulings1

g g

s2s3

h

s4

j

(cl,rl)(cl,rl)

(cl,rl)

(cl,rl)

h

j

(cl,rl)

(cl,rl)

T1

p

T2T3

q

T4

r

(cl,rl)

(cl,rl)

(cl,rl)

U1

v v

U2

U3

w

(cl,rl) (cl,rl)

(cl,rl)

w(cl,rl)

Resource Management Policye.g. scheduler

Resource

g(cl,rl)

p

(cl,rl)

v

(cl,rl)

g(cl,rl)

q

(cl,rl)

w

(cl,rl)

h(cl,rl)

r

(cl,rl)

v

(cl,rl)(cl,rl)

v

(cl,rl)

h(cl,rl) .. etc

17 42 253

e.g. EDF, CBS, …


Scenario SimulationTask instance

triggeringTask instance

completionTask instance

deadlineCPU is idle

Simulation time

Simulation time

Bu

s lo

ad

Simulation time

Me

mo

ry u

sag

e


x y z

Parser Analyser Inheritance RelatorDB Creator DB Filler DB Checker

Analyser Inheritance RelatorDB Creator DB Filler

resource R claim 100 release 100

1. Composition of System Structure

2. Composition of Logical Behaviourof whole system

C1 C2

3. Composition of Execution Behaviour- tasks- resource mng policies

C1 C2S

platformRM

10

20

30

40

50

60

0init do task x do task x dispose

c +

c +

c +

c +

c +

c +

c +

Summary of Recipy for Predictable Assembly

system model

4. Analyse

0. Definition of Scenarios


Evaluating Architectural Alternatives

22 MIPS

MMI_Inst

113 MIPS 11 MIPS

72 kbps

(A)

NAV_Inst RAD_Inst

22 MIPS

MMI_Inst

113 MIPS 11 MIPS

72 kbps(B)

NAV_Inst RAD_Inst

57 kbps

22 MIPS

MMI_Inst

260 MIPS

72 kbps

(C)

NAV_Inst

RAD_Inst

260 MIPS

MMI_Inst

RAD_Inst

NAV_Inst(E)

Hardware node Hardware linkSw Component

130 MIPS

MMI_Inst113 MIPS

72 kbps

(D)

NAV_Inst

RAD_Inst


Graphical Composer


Sce

nario

Sim

ula

tion

App

roa

ch

Specification ofsoftware component

composition

Specification ofhardware architecture

Software arch

Hardware arch

Mapping the SWcomponents on the HW

nodes

System architecture

Task Graph Generation

Task Execution Architecture

Simulation of the taskarchitecture

Predicted system behaviour

Extracting qualityattributes (latency, bus,

cpu load, sensitivity)

Multi-objective Paretoanalysis

RedesignRemapping

RTIE Graphical Composer

RTIE

Repos

itory

RTIE Models

Compiler

RT

IE T

ask

Generator

RT

IE S

imul

ator

RTIE VisualizerRTIE Reporte

r

Weighting

technique

Predicted QAs

Design Flow


Evaluation of the method Predict XF-Q properties based on black-box components Compositional (supports third-party binding) Method can be used throughout development cycle

(design / implementation / run-t) with incremental accuracy The method can be applied to different types of resources Supports dynamic resource management policies The method can support different types of analyses

• (Worst-Case, Best-Case, …)

Scenario’s• Do not give 100% guarantees as usual in formal methods

• Do allow incremental accuracy: focus on what is important


Questions?

Documents

November 21, 2005Egor Bondarev, Michel Chaudron, Peter de With Evaluating Quality Properties of Component-based Software Architectures Egor BondarevMichel