spacer
spacer search

The Embedded Components Website
Hosted by the IST COMPARE Project

Search
spacer
Newsflash
Vincent Seignole has presented the COMPARE approach at the OMG Workshop on Distributed Real-time Embedded Systems.

Get the PDF.

 
COMPARE Machine
Main Menu
Home
News
Links
Documents
Contact Us
Downloads
News Feeds
FAQ's
Blog
COMPARE Vision
Search
Administrator
 
Home arrow Documents arrow COMPARE Documents arrow COMPARE Vision

COMPARE Vision Print E-mail
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 )
 
< Prev
spacer
 
© 2020 The Embedded Components Website
Joomla! is Free Software released under the GNU/GPL License.
spacer