Post on 21-Dec-2015
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.