component-based approach for embedded...
TRANSCRIPT
1
2004-11-29
Component-based approach for embedded systems
Ivica CrnkovicMälardalen University
Department of Computer Science and Engineering,Mälardalen Real-time Research Centre
Swedenhttp://www.idt.mdh.se/~icc
2
2004-11-29
Mälardalen University (MdH)Mälardalen University, Vasteras (Västerås)
Department of Computer EngineeringReal-Time Systems Design Lab Computer Architecture LabComputer Science LabSoftware Engineering Lab
Prof. in Software Engineering http://www.idt.mdh.se/[email protected]
3
2004-11-29
Outline• Basic characteristics of Component-based Software
Engineering• Component-based approach in different domains –
benefits and challenges• Embedded systems – some examples• Different types of embedded systems – concerns• Component models for embedded systems (examples) • Needs and challenges, research directions
4
2004-11-29
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
2004-11-29
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
application
Component#1
Component#2
Component#3
Component#4
Component
#1
Component
#2
Component
#3
Component
#4
6
2004-11-29
Implications• 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
Requirements
Specification
Design
Implementation
TestDeploy
Find & Select
Adapt
Test
Applicationdevelopment
Componentdevelopment
Operation &Maintenance
7
2004-11-29
CBSE process issues
• Different types of approaches– Using components as well defined design units– Product-line approach
• Building many variants and versions of a products based on the same architecture and varying components. Components are developed in-house
– COTS (Commercial off the shelf) components• Building systems from existing components
8
2004-11-29
Main principles: (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
9
2004-11-29
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
10
2004-11-29
Substitution principles• When we can replace a component?• Functional properties
– Substitution OK if it accepts wider range of input and provides smaller range of output
• What about Real-time properties?– new components must not be faulty– schedulability of all tasks must be guaranteed
• Existing approach – Sha 1998– basic idea: monitor output to ensure values within valid range– run-time upgrade possible if
WCET (new comp) ≤ WCET (old comp)
– Is that correct?
11
2004-11-29
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 FPStask priority
A high
B medium
C low
12
2004-11-29
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)
13
2004-11-29
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
14
2004-11-29
Main principles: (4) composability• Composition of components
– F(c1 o c2) =F1(c1) o F2(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
Example:Pipe & filter:F(c1 o c2)(x)= F1(F2(x))
15
2004-11-29
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.
16
2004-11-29
Describing a Component
• To be able to describe a component completely the component should consist of the following elements:
– A set of interfaces provided to, or required from the environment.– An executable code, which can be coupled to the code of other
components via interfaces.• How to specify a component?
black boxblack box white boxwhite box glass boxglass boxgrey boxgrey box
17
2004-11-29
Interface specification
• Construction interface (Operations)• Pre-, post-conditions and invariants• Specification of extra-functional properties
– Run-time properties• Performance, latency• Dependability (Reliability, robustness, safety)
– Life cycle properties• Maintainability, usability, portability, testability,….
18
2004-11-29
Experience in use of component technologies
• Many successes– Office applications– Graphical/desktop applications – Information systems– Distributed applications (web-based)– Particular domains (GIS), Telecommunication, consumer
electronics,…
• Several component technologies widely used– Ms COM/DCOM– Ms .NET– Sun EJB, J2SEE– OMG CORBA, Corba CM
19
2004-11-29
How much is CBSE attractive for different domains?
• Advantages from a 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 usability, interoperability, flexibility, adaptability,
dependability…
• Advantages from strategic point of view of a society – Increasing software market, generation of new companies
20
2004-11-29
Do existing component technologies meet the requirements of different domains?
• Widely-used component models (Microsoft COM/DCOM and .NET, Sun EJB,J2SEE, OMG Corba CM,…)
– Focus on functionality, flexibility, run-time adaptability, simpler development and maintenance
– Do not consider non-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?
21
2004-11-29
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,99% of computer systemsare embedded systems (DARPA 2000)
22
2004-11-29
Embedded(how many computers do you see?)
23
2004-11-29
Example: 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
24
2004-11-29
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
25
2004-11-29
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
26
2004-11-29
Basic concepts for Component-based Embedded Systems
• Main concern– Predictability of different properties (on
account of flexibility)
• Difference between small and largeembedded systems
27
2004-11-29
Component models for small embedded systems vs. General-purpose component models
Small Embedded Systems• Composition time separated form
run-time• Optimization at configuration time
(direct references, unneeded functionality removed)
• Explicit context dependencies• Run-time environment (CPU,
RTOS, resource constraints)
• Fine-grained
• Reuse & portability• white, glass, or grey box
components• source code portability
General-purpose components• Run-time composition (late
binding) • Set of interfaces, “bugs” of
services
• Contractual-based interfaces• Not resource-usage aware
• Coarse-grained
• Portability - Binary independence (Black-box reuse)
28
2004-11-29
Component-based approach for LARGEembedded 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.
29
2004-11-29
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.
30
2004-11-29
OPC (OLE for Process Control)• industry standard for communication between
components in field devices, automation equipment and business applications (generic driver)
• data model• set of interfaces for COM
– server interfaces– callback interfaces
• managed by OPC Foundation (www.opcfoundation.org)
31
2004-11-29
OPC: How does OPC Solve the Problem?
SoftwareDriver
SoftwareDriver
SoftwareDriver
SoftwareDriver
OPC OPC OPC OPC
DisplayApplication
TrendApplication
ReportApplication
OPC OPC OPC
32
2004-11-29
Some examples of componentmodels for embedded systems
33
2004-11-29
Thanks to Rob van Ommering Philips ResearchEindhoven, The Netherlands
KOALA COMPONENT MODEL
34
2004-11-29
The Koala Component Model
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
35
2004-11-29
PECOS Component Model - ABB (Pervasive Component Systems)
Device Builder
Component Library• function blocks• asset management• parameter storage• display
Component Library• function blocks• asset management• parameter storage• display
Composition Environment
• composition development• code generation for run-
time• check component
compatibility
Composition Environment
• composition development• code generation for run-
time• check component
compatibility
Run-time Environmentoptimized, ultra-light run-timeexperimental Java-based run-time
Run-time Environmentoptimized, ultra-light run-timeexperimental Java-based run-time
36
2004-11-29
Property
keyvalue
PropertyBundle
name
Port
typeDirectionrange
Connector
typeComponent
name
scheduling
memory
Sub-components
Eventcomponent
Activecomponent
passivecomponent
event info
thread info
Pecos component model
37
2004-11-29
Example - Adoption of a general-purpose component model
ABB Controller - Componentization of a system• Requirements
– Improve the development process• Distributed development• Shorter time-to-market Redefined architecture
• Conditions:– Keep the main requirements (real-time) unchanged
• Solution– Componentize the software architecture– Use of a subset of a component model (COM)
38
2004-11-29
Use of the Component Object Model (COM)
• COM is a public specification (by Microsoft) which emphasizes separation of interfaces and implementation
• A well-defined subset of the COM specification has been adopted • COM compliant interfaces can be used on platforms without COM
run-time support• On platforms with COM run-time support:
– Protocol handlers implemented as COM classes• On platforms without COM run-time support:
– Protocol handlers implemented as C++ classes, which must be statically linked with the framework
39
2004-11-29
Conclusion: What are the needs?
• Need for component models and frameworks for embedded systems. – the run-time platform must provide certain services, which however
must use only limited resources.• Obtaining extra-functional properties of components in
particular timing and performance properties. • Component certification• Platform and vendor independence • Component noninterference applications, (in terms of
memory protection, resource usage, etc).• Tool support: The adoption of component technology
depends on the development of tool support.
40
2004-11-29
References• Conferences and Workshops
– Component-based Software engineering Symposium:• http://www.sei.cmu.edu/pacc/CBSE7/• http://www.sei.cmu.edu/pacc/CBSE8/
– Euromicro conference, CBSE track• http://www.idt.mdh.se/ecbse/2004/• http://www.idt.mdh.se/ecbse/2005/
– WCOP International Workshop on Component-Oriented Programming• http://research.microsoft.com/~cszypers/events/wcop2004
– International Working Conference on Component Deployment• http://cd04.cs.ucl.ac.uk/
– Workshop on Component Composition