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 [email protected]
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.