Written by Administrator
|
Sunday, 17 July 2005 |
This document describes the COMPARE vision on the role that embedded component technologies can plany in the implemenation of software intensive embedded systems.
Compare vision and goals
Component approaches are currently emerging in the scope of engineering
real-time and embedded systems.
Current issues in traditional approaches:
This trend is mostly due to a set of concerns we will detail below,
which make the composition approach relevant in order to treat them:
- portability concerns: Developments need to be reused at least
as part of product lines, and beyond. For that, an adequate granularity
for decomposition is needed. The market of RTOSes and middlewares for
embedded systems is still very heterogeneous, each comes with its
specific features. Most middleware used in such systems are in house
middleware. In order to cope with this myriad (plethora) of
technologies, traditional approaches have focused on the
provision of common layers to abstract the underlying
capabilities. But these approaches suffer from different problems:
maintaining RTOS/middleware abstraction layers is overly costly, and
sometimes finding some common semantics of considered APIs is tricky
and the outcome often is loss of semantics.
- reusability concerns: Developments need to be reused at least
as part of product lines, and beyond. Most reusability problems come
from the fact that implicit dependencies are present in building-blocks
(e.g classes). These dependencies can be of different types: to other
implementations, to specific files (programming language level). Thus,
a clean declaration of dependencies of building blocks is needed.
(put that in footnote): Additionally, the notion of reuse can be linked
to the previous item listed: "portability", since "portability" means
"reusability in a different RTOS / middleware environment", as well as
"hardware" environment: portability is an enabler for reusability
across different platforms.
- integration concerns: gathering and making the developments
of different parties collaborate gracefully traditionally represents
most of the efforts to deliver a product.
- expertise under-exploitation concerns:
with traditional approaches, experts can not only focus on their added
value, but also must master the technologies.
- time to market:
- cost in production:
- need for improvement of productivity:
How are/can these issues be addressed
by component based approches ?
- portability: We want to emphasize that the approach taken by
Compare is not to deal
with portability via provision of common APIs wrapping different
possible RTOS or
middleware targets, and is fundamentally different. We take full
advantage of
component-orientation to move to descriptions and accompanying mappings
to
target platforms, which allows to make a big step forward in terms of
portability.
On a more technical side, we have to provide suitable mechanisms
to replace the programming of timers, mutexes and so on, by a declarative
specification of the behavior. The result is
is that we end up with "golden-source" stripped from non-functional
aspects, and these
aspects are supported fully separately via the component-container
pattern.
- reusability: component based approaches are enforcing the
(formal) definition of dependencies via description languages: in the
case of CCM, the IDL3 language is used to define functional
dependencies, and component descriptors (XML based) to define technical
dependencies.
The dependencies are twofold:
-description of component binaries in terms of target processor
architecture, needed libraries, ...
- description of component assemblies together with technical
features needed to be applied.
Another key feature of component orientation enhancing
reusability results from the production of "component packages". They
encapsulate component binaries as well as their descriptors.
Footnote: Reusability profits from the definition of domain
standard interfaces.
(in a team, company, or industry-wide). The use of components can
promote
adoption of such standards.
A suitable granularity has to be found for reuse. This is sometimes
domain related. Component
technologies are appropriate for wrapping functions to be reused as
part of product-lines, at the
granularity envisioned by the system designer.
- integration: a component based approach comes with a set of
engineering rules for components (example: programming rules, among
others), which can be applied in a transverse manner in teams
collaborating for the elaboration of a product. Having these rules
followed imply composability, which means: integration.
What and how we do.
The goal of the Compare project is to primarily focus on the
"Separation of concerns", as it will be a quite important enabler for
portability and reusability. Going into separation of concerns leads to
making the transition from "programming" to "describing", and most of
this involves the introduction of formalisms to provide these
descriptions.
- encapsulation and gatewaying of legacy: reusing previous
developments or systems which did conform to ad-hoc or different
technology spaces is very difficult. |
Last Updated ( Monday, 09 October 2006 )
|