Component-based approach for embedded systems

Ivica Crnkovic
Mälardalen University, Department of Computer Science and Engineering,
Box 883, 721 23 Västerås, Sweden
ivica.crnkovic@mdh.se, www.idt.mdh.se/~icc
Abstract: This paper addresses component-based approach development of real-time and embedded systems is
for embedded systems. Due to the specific characteristics of significantly slower. Major reasons are that embedded
embedded systems the general-purpose component systems must satisfy requirements of timeliness, quality-
technologies such as COM, .NET, or EJB have not been the of-service, predictability, that they are often safety-critical,
most appropriate choices for their development. Although and can use severely constrained resources (memory,
attractive, component-based approach has not been processing power, communication). The widely used
successful in this domain as in other domains. However in component technologies such as EJB, .NET, CORBA
recent years the interest for component-based approach in component models are inherently heavyweight and
embedded systems increases. The experience has shown complex, incurring large overheads on the run-time
that existing technologies cannot be used, or at least used platform; they do not in general address timeliness,
directly. On the other hand an increasing understanding of quality-of-service or similar extra-functional properties
principles of component-based approach makes it possible that are important for real-time systems. In their present
to utilize these principles in implementation of different form they start to be deployed in large, distributed, and not
component-based models, more appropriate for embedded safety critical systems, e.g., in industrial automation, but
systems. This paper gives an overview of basic are not suitable for deployment in most embedded real-
characteristics of embedded systems, their requirements and time environments.
constraints, and the implications to component models for
This paper gives a short overview of basic characteristics
these systems.
of embedded software and the problems and challenges
the developers met. Further it describes a current state of
1 Introduction the practice in different industries and research trends in
Embedded systems cover a large range of computer applying component-based principles for embedded
systems from ultra small computer-based devices to large systems. The paper is based on work and results of several
systems monitoring and controlling complex processes. The research projects, EU IST ARTIST1, CBSENet Network2
overwhelming number of computer systems belongs to Swedish SAVE3 project, and on communication and
embedded systems: 98% of all computer systems belong to cooperation with several companies such as ABB, Volvo,
embedded systems today. IEEE has the following definition Ericsson and Philips.
for embedded systems:
The rest of the paper is organized as follows. Section 2
An Embedded Computer System: A computer system that is gives and general characteristics and the most important
part of a larger system and performs some of the requirements of embedded systems. Section 3 gives some
requirements of that system; for example, a computer examples of embedded systems in which a component-
system used in an aircraft or rapid transit system. (IEEE, based approach has been used or has recently being
1992). developed. Chapter 4 lists the basic characteristics of
component-based approach for embedded systems and
Most of such embedded systems can also be characterized
finally chapter 5 summarizes the current challenges and
as real-time systems, (i.e., systems in which the correctness
need for further research.
of the system depends not only on the logical result of the
computations it performs but also on time factors [9]).
Embedded real-time systems contain a computer as a part 2 Specific requirements of embedded
of a larger system and interact directly with external systems
devices. They must usually meet stringent specifications for In most of the cases embedded systems are real-time
safety, reliability, limited hardware capacity etc. The systems. In many cases embedded systems are safety or
increased complexity of embedded real-time systems leads mission critical systems. Embedded systems vary from
to increasing demands with respect to requirements very small systems to very large systems. For small
engineering, high-level design, early error detection, systems there are strong constrains related to different
productivity, integration, verification and maintenance. recourses such as power or memory consumption. For
Component-based development is an attractive approach in these as well as for large embedded systems the demands
the domains of embedded systems. In particular for the
development of many variants of products the component- 1
http://www.systemes-critiques.org/ARTIST
based approach is attractive. In spite of this attractiveness 2
http://www.cbsenet.org
the adoption of component-based technologies for the 3
http://www.mrtc.mdh.se/SAVE
on reliability, robustness, availability and other etc.) and maintenance (adaptive maintenance, debugging,
characteristics of dependable systems are important. regressive testing, etc.) require a lot of efforts. For these
Finally, in many domains, the product life cycle is very reasons the technologies and processes that lead to lower
long – in can stretch to several decades. costs for these activities are very attractive and desirable.
All these characteristics have strong implications on
requirements. Most of the requirements of embedded 3 State of the practice and experience for
systems are related to non-functional characteristics (better Embedded Systems
designated as extra-functional properties or quality Embedded systems comprise a scale from ultra small
attributes). These properties can be classified in run-time devices with simple functionality, through small systems
and life cycle extra-functional properties. The most with sophisticated functions, to large, possibly distributed
important are: systems, where the management of the complexity is the
- Real-time properties. The real-time system functions main challenge. Further we can distinguish between
are time-related; a violation of time requirements even systems produced in large quantities, in which the low
of a proper functional response violates the system production costs are very important and low-volume
functionality. There are numbers of real-time products in which the system dependability is the most
properties: Response time or latency, execution time, important feature. All these different requirements have
worst case execution time, deadline etc. impact on feasibility, on use, and on approach in
component-based development. A common characteristic
- Dependability. Dependability is defined as an ability of of all systems is increasing importance of software. For
a system to deliver service that can justifiably be example, software development costs for industrial robots
trusted and an ability of a system to avoid failures that make today about 75% of total costs, while in car industry
are more severe and frequent than is acceptable to the it is today about 30%. Some ten, fifteen years ago this
users. The main means to attain dependability are number was about 25% for robots and neglectable for cars.
related to avoidance of faults: fault prevention, fault A second common characteristic is increasing
tolerance, fault removal and fault forecasting [1]. interoperability. While previously the embedded systems
Dependability is characterised by several attributes and were mainly used for controlling different processes today
according to [1], these are the following: Reliability, they are integrated with information systems of
availability, integrity, safety, confidentiality and infotainment technologies.
maintainability. All these attributes are run-time
properties except maintainability. These attributes are In this section we give a short overview of some typical
combination of several properties. For example embedded systems.
availability is dependent on real-time properties, but
also on reliability and even maintenance; safety is 3.1.1 Automotive Industry
strongly related to reliability, etc. Cars are typically manufactured in volumes in the order of
millions per year. To achieve these volumes, and still offer
- Resource consumption. Many embedded systems have
the customer a wide range of choices, the products are
strong requirements for low and controlled
built on platforms that contain common technology that
consumption of different resources. The reasons may
have the flexibility to adapt to different kinds of cars by
be the size of the systems and/or the demands on lower
adding different components or different variants of the
production costs. Examples of such restrictions and
components.
constraints are power and memory consumption,
execution (CPU) time, computation (CPU) power, etc. The components are to a large extent provided by external
suppliers, who work with many different car companies
- Life cycle properties. In general embedded systems are
(or OEMs, original equipment manufacturers). The role of
tightly coupled with their environment and the absence
the OEM is thus to provide specifications for the
of their services can have large consequences on the
suppliers, so that the component will fit a particular car,
environment. In many domains the embedded systems
and to integrate the components into a product.
have very long life time running round the clock year
Traditionally, suppliers have developed physical parts, but
after year. During the lifetime of a system several
in modern cars they also provide software.
generations of hardware and software technologies can
be used. The long life systems must be able to cope Within the automotive industry, the component-based
with these changes introduced either into the approach has a relatively long tradition, as these systems
surrounding environment or into the systems are typically built from system components that are either
themselves. developed in-house or provided by external suppliers.
Today, the entire control system of an advanced car
We can conclude that many of the most important
includes a number of Electronic Control Units (ECUs)
requirements of the embedded systems are related to extra-
equipped with software that implements vehicle functions.
functional properties. This has an implication that
ECUs are treated as system components that can be
development and maintenance of such systems are very
developed and build independently of each other and of
costly. In particular activities related to verification and
the entire system. A system control architecture is shown
guaranteed behavior (formal verification, modeling, tests,
in Figure 1. The ECUs are connected to the system (the
car) through sensors and actuators and between themselves and overview the entire process to be controlled, (v)
via one or several buses. Usually the buses are integrations Production or manufacturing management level that
points and their protocols specify the communications includes systems and applications for production planning.
between the ECUs.
Notice that, even if the higher levels are not embedded,
they are of uttermost importance as they need to be
interoperable with the lower level which greatly influences
gateway the possible choices of the component model and in fine
(CAN) BUS
the design choices. The integration requirements have in
ECU ECU ECU
many cases led to a decision to use component
technologies which are not appropriate for embedded
Sensor
Sensor Actuator Sensor Sensor
Sensor Actuator
systems but provide better integration possibilities.
Sensor Actuator
Depending on the level, the nature of the requirements and
the implementation will be quite different. In general, the
Vehicle mechanics lower the level, the stronger are the real-time requirements
Figure 1. Component-based architecture of vehicular (including timing predictability) and the resource
systems limitations. Also, the component based approach will
include different concepts at different levels. While at the
Modern vehicular systems contain several tens of computer lowest levels availability, timeliness, and reliability are the
nodes. As the number of ECUs increases, the entire system most important quality requirements, at higher levels it
becomes more complex. This requires sharing different will be performance, usability, and integrability.
types of resources (sensors, actuators, time,
communication, memory, and CPU consumption). With 3.1.3 Consumer Electronics
increasing complexity, system reliability and safety become
Consumer electronics products, such as TV, VCR, and
major problems. A satisfactory handling of safety-critical
DVD, are developed and delivered in form of product
functions, such as emerging brake and steer-by-wire
families which are characterized by many similarities and
systems, require the integration of methods for establishing
few differences and in form of product populations which
components and compositions of different aspects:
are sets of products with many similarities but also many
functional and temporal correctness, safety and reliability,
differences. Production is organized into product lines -
etc.
this allows many variations on a central product definition.
Today ECUs include proprietary software, mostly owned A product line is a top-down, planned, proactive approach
by subcontractors. This makes the entire system inflexible to achieve reuse of software within a family or population
and inefficient in utilizing resources, makes it difficult to of products. It is based on use of a common architecture
implement complex functions, and expensive to add new and core functions included into the product platform and
ECUs. The next major step in designing these systems is to basic components. The diversity of products is achieved
go from the current situation with one node one supplier to by inclusion of different components. Because of the
a situation with one node several suppliers, i.e. there will be requirements for low hardware and production costs,
several software components of different origins executing general-purpose component technologies have not been
on a typical node. Also to enable delivery of more complex used, but rather more dedicated and simpler propriety
applications, it should be possible to spread out software models have been developed. An example of such a
components through several nodes. component model is the Koala component model used at
Philips [13,14]. Koala is a component model and an
3.1.2 Industrial Automation architectural description language to build a large diversity
Typical application domains of industrial automation are in of products from a repository of components. Koala is
control of industrial processes, power supply, industrial designed to build consumer products such as televisions,
robots. Industrial automation domain comprises a large area video recorders, CD and DVD players and recorders, and
of control, monitoring and optimization systems. They combinations of them.
typically include large pieces of software that have been
developed over many years (often several decades). Most 3.1.4 Other domains
control systems are manufactured in rather large volumes, There are many domains in which embedded systems are
and must to a large extent be configurable to suit a variety used extensively. Some of them are: Telecommunication,
of customer contexts. They can be classified according to avionics and aerospace, transportation, computer games,
different levels of control [4]: (i) Process level (for home electronics, navigation systems, etc. While there is
example, a valve in a water pipeline, a boiler, etc.), (ii) many similarities between these domains there are also
Field level that concerns sensors, actuators, drivers, etc. (iii) very different requirements for their functional and extra-
Group control level that concerns controller devices and functional properties. The consequences are that the
applications which control a group of related process level requirements for component-based technologies are
devices in a closed-loop fashion, (iv) Process control level different, and consequently we cannot expect to have one
i.s. operator stations and processing systems with their component model. The expectations are that many
applications for plant-wide remote supervision and control component models will coexist, sharing to less or larger
extent some common characteristics, such as basic of system requirements and prediction of system
principles of component specifications through interfaces, properties from properties of components.
basic composition and run-time services, certain patterns,
In general-purpose component technologies, the interfaces
and similar.
are usually implemented as object interfaces supporting
polymorphism by late binding. While late binding allows
4 Basic concepts for Component-based connecting of components that are completely unaware of
Embedded Systems each other beside the connecting interface, this flexibility
In classic engineering disciplines a component is a self- comes with a performance penalty and increased risk for
contained part or subsystem that can be used as a building system failure. Therefore the dynamic component
block in the design of a larger system. In software deployment is not feasible for small embedded systems.
engineering, there are many different suggestions for Taking into account all the constraints for real-time and
precise definitions of components in component based embedded systems, we can conclude that there are several
software development. The best accepted understanding of reasons to perform component deployment and
component in the software industry world is based on composition at design time rather than run-time [4]: This
Szyperski’s definition [11]. From this definition it can be allows composition tools to generate a monolithic
assumed that a component is an executable unit, and that firmware for the device from the component-based design
deployment and composition can be performed at run-time. and by this achieve better performance and better
In the domains of embedded systems this definition is predictability of the system behavior. This also enables
largely followed, in particular the separation between global optimizations: e.g., in a static component
component implementation and component interface. composition known at design time, connections between
However the demands on the binary or executable from is components could be translated into direct function calls
not directly followed. A component can be delivered in a instead of using dynamic event notifications. Finally,
form of a source code written in a high-level language, and verification and prediction of system requirements can be
allows build-time (or design-time) composition. This more done statically from the given component properties.
liberal view is partly motivated by the embedded systems This implies that the component-based characteristic is
context, as will be discussed in below. mostly visible at design time. To achieve an efficient
Many important properties of components in embedded development process tools should exist which will provide
systems, such as timing and performance, depend on support for component composition, component
characteristics of the underlying hardware platform. Kopetz adaptation and static verification and prediction of system
and Suri [3] propose to distinguish between software requirements and properties from the given component
components and system components. Extra-functional properties.
properties, such as performance, cannot be specified for a There may also be a need for a run-time environment,
software component in isolation. Such properties must which supports the component framework by a set of
either be specified with respect to a given hardware services. The framework enables component
platform, or be parameterized on (characteristics of) the intercommunication (those aspects which are not
underlying platform. A system component, on the other performed at design time), and (where relevant) control of
hand, is defined as a self-contained hardware and software the behavior of the components.
subsystem, and can satisfy both functional and extra-
functional properties. Figure 2 shows different environments in a component life
cycle. The figure is adopted from [4].
4.1 Component-based approach for small Component model Composition framework Execution framework
embedded systems Components

The specific characteristics of embedded systems lead to

specific requirements of component technologies. In
particular the approaches in development process and
component specifications using interfaces are different
form those implemented in the component technologies
widely used in other domains.
Component Composition Run-time
Repository environment environment
The component interface summarizes the properties of the
component that are externally visible to the other parts of
the system. As for embedded systems non-functional Figure 2. Component technology for small embedded
properties are as important as functional there is a tendency systems
to include specification of extra-functional properties in the
component interface (for example timing properties). This
allows more system properties to be determined when the
system is designed, i.e. such interface enables verification
4.2 Component-based approach for large (IDL), and some basic services at run-time such as
embedded systems component deployment has been used. These services
have been implemented internally. Different
For large embedded systems the resource constraints are communication protocols and I/O drivers have been
not the primary concerns. The complexity and identified as components (see Figure 3).
interoperability play much more important role. Also due
complexity the development of such system is very
expensive and cutting the development costs is highly 5 The needs and priorities in research
prioritized. For this reason general-purpose component The component-based approach on system level, where
technologies are of more interesting than in a case for small hardware components are designed with embedded
systems. software, has been successfully used for many years. Also
The technology mostly used in large systems is Microsoft large-grain generic components like protocol stacks,
COM and recently .NET, and to smaller extent different RTOSs, etc. have been used for a long time. In addition to
implementations of CORBA, although no one of these this, technology supporting a component-based approach
technologies provide support for real-time. The systems has been developed; either in the form of proprietary
using these technologies belong to the category of soft-real component models, or by using reduced versions of some
time systems. Often a component technology is used as a widely used component models.
basis for additional abstraction level support, which is Still, there are needs for a number of improvements. Some
specified either as standards or proprietary solutions. The of them are the following (differently important for
main reason for wide use of component-based technology is different domains):
the possibility of reusing solutions in different ranges of
products, efficient development tools, standardized - There is a lack of widely adopted component
specifications and interoperation, and integration between technology standards which are suitable for embedded
different products. systems. For smaller-size embedded systems, it is
important that a system composed of components can
One successful example of adoption of a component-based be optimized for speed and memory consumption,
technology is the initiative OPC Foundation (OLE process which is still missing in most of the component
control Foundation, www.opcfoundation.org), an technologies available today.
organization that consists of more than 300 member
companies worldwide, is responsible for a specification that - There is also a need for interoperability between
defines a set of standard interfaces based upon Microsoft’s different component technologies. Specification
OLE/COM and recently .NET technology. OPC consists of technology is not sufficiently developed to guarantee
a standard set of interfaces, properties, and methods for use a priori component interoperability.
in process-control and manufacturing-automation - Most current component technologies do not support
applications. OPC provides a common interface for important extra-functional properties.
communicating with diverse process-control devices,
regardless of the controlling software or devices in the - There is a need for generic platform services, for, e.g.,
process. The application of the OPC standard interface security and availability.
makes possible interoperability between automation/control - Tools that support component based development are
applications, field systems/devices and business/office still lacking.
applications.
- There is a lack of efficient implementations of
Another example of a component-based approach is component frameworks (i.e., middleware), which
development and use of the standard IEC 61131 [5]. IEC have low requirements on memory and processing
61131 defines a family of languages that includes power.
instruction lists, assembly languages, structured text, a high
level language similar to Pascal, ladder diagrams, or Major needs for the further development of component
function block diagrams (FBD). Function blocks can be technology for embedded systems are the following [16].
viewed as components and interfaces between blocks are
- Need for adopted component models and frameworks
released by connecting in-ports and out-ports. Function
for embedded systems. A problem is that many
block execution may be periodic or event-driven. IEC
application domains have application-dependent
61131 is successfully used in development of industrial
requirements on such a technology.
process automation systems for many years.
- Need for light-weight implementations of component
Large embedded systems that must fulfill real-time
frameworks. In order to support more advanced
requirements usually do not use general-purpose
features in component-based systems, the run-time
component-based technologies. However in some cases,
platform must provide certain services, which
such as for ABB controllers, a reduced version of COM has
however must use only limited resources.
been used on a top of a real-time operating system [6]. The
reused version includes facilities for component - Obtaining extra-functional properties of components:
specification using the interface description language Timing and performance properties are usually
 obtained from components by measurement, usually by Engineering Institute, Carnegie-Mellon
means of simulation. Problems with this approach are University, May 2000.
that the results depend crucially on the environment
3. H. Kopetz and N. Suri. Compositional design of
(model) used for the measurements may not be valid in
RT systems: A conceptual basis for specification
other environments, and that the results may depend on
of linking interfaces. In Proc. 6th IEEE
factors which cannot easily be controlled. Techniques
International Symposium on Object-oriented
should be developed for overcoming these problems,
Real-Time Distributed Computing (ISORC),
thereby obtaining more reliable specifications of
Hokkaido, Japan, May 2003.
component properties.
4. I. Crnkovic and M. Larsson. Building Reliable
- Platform and vendor independence: Many current
Component-Based Software Systems.
component technologies are rather tightly bound to a
ArtechHouse, 2002.
particular platform (either run-time platform or design
platform). This means that components only make 5. IEC. Application and implementation of IEC
sense in the context of a particular platform. 61131-3. Technical report, IEC, Geneva, 1995.
- Efforts to predict system properties: The analysis of 6. F. Lüders, I. Crnkovic, and A. Sjögren. Case
many global properties from component properties is study: Componentization of an industrial control
hindered by inherent complexity issues. Efforts should system. In Proc. 26th Annual International
be directed to finding techniques for coping with this Computer Software and Applications Conference
complexity. - COMPSAC 2002, Oxford, UK, Aug. 2002.
IEEE Computer Society Press.
- Component certification: In order to transfer
components across organizations, techniques and 7. OMG. Response to the OMG RFP for
procedures should be developed for ensuring the schedulability, performance, and time (revised
trustworthiness of components. submission), June 2001. OMG, RFP ad/2001-06-
14.
- Component noninterference: Particularly in safety-
critical applications, there is a need to ensure 8. OMG. A uml profile for enterprise distributed
separation and protection between component object computing, June 18 2001. ptc/2001-12-04.
implementations, in terms of memory protection,
9. Stankovic J. and Ramamritham K., "Tutorial on
resource usage, etc.
Hard Real-Time Systems", IEEE Computer
- Tool support: The adoption of component technology Society Press, 1998.
depends on the development of tool support.
10. J. Siegel and the O.S.S. Group. Developing in
The clearly identified priorities of CBSE for embedded OMG’s model-driven architecture, Nov. 2001.
systems are: OMG, White paper, Revision 2.6.
- Predicting system properties. A research challenge 11. C. Szyperski. Component Software: Beyond
today is to predict system properties from the Object-Oriented Programming. ACM, Press and
component properties. This is interesting for system Addison-Wesley, New York, N.Y., 1998.
integration, to achieve predictability, etc.
12. C. Szyperski. Component Software: Beyond
- Development of widely adopted component models for Object-Oriented Programming. Second edition,
real-time systems. Such a model should be supported ACM, Press and Addison-Wesley, New York,
by technology for generating necessary runtime N.Y., 2002.
infrastructure (which must be light-weight), generation
of monitors to check conformance with contracts, etc. 13. R. van Ommering, F. van der Linden, and J.
Kramer. The Koala component model for
consumer electronics software. IEEE Computer,
6 References 33(3):78–85, March 2000.
1. Avižienis A., Laprie J-C., Randell B., 14. R. van Ommering. Building product populations
Fundamental Concepts of Computer System with software components. In Proceedings of the
Dependability, IARP/IEEE-RAS Workshop on 24th international conference on Software
Robot Dependability: Technological Challenge of engineering,. ACM Press, 2002.
Dependable, Robots in Human Environments,
2001. 15. N. Wang, D. Schmidt, and C. O’Ryan. Overview
of the CORBA Component Model, Sept. 2000.
2. F. Bachmann, L. Bass, C. Buhman, S. Comella- White paper.
Dorda, F. Long, J. Robert, R. Seacord, and K.
Wallnau. Technical Concepts of Component- 16. E. Brinksma et al., ROADMAP - Component-
Based Software Engineering, Volume II. Technical based Design and Integration Platforms,
Report CMU/SEI-2000-TR-008, Software W1.A2.N1.Y1, Project IST-2001-34820,
ARTIST - Advanced Real-Time Systems