Upload
nehemiah-halton
View
213
Download
1
Tags:
Embed Size (px)
Citation preview
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
Outline Introduction & Context Problem statement Approach
• scenario-based predictable assembly
Conclusion
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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?
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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 …
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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:
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
Example Problem: Car Navigation System (CNS)
MMI
NAV
RAD
MapDB
MMI = Man-Machine Interface
RAD = Radio controller
NAV = Navigation Software
Logical ViewEnvironment
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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)
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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, …)
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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)
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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, …
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
Graphical Composer
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
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
November 21, 2005 Egor Bondarev, Michel Chaudron, Peter de With
Questions?