Foundations of Component Based Development

Proposal for an ARTIST_ACTION draft 17/10/2001

A BRIEF RATIONALE

Component based design is perceived as a key technology for developing advanced real-time systems in a both cost- and time effective manner. Already today, component based design is seen to increase software productivity, by reducing the amount of effort needed to update and maintain systems, by packaging solutions for re-use, and easing distribution. In an ideal scenario, application development could follow a "drop & glue" approach, picking components from a library incorporating the intellectual property of the system house as well as standardized components, giving to the system developer a range of re-usable components supporting all layers of a system architecture. The OMG´s Model-Driven Architecture approach is an initiative to enhance re-use across multiple implementation platforms, by separating functional modeling from deployment architectures

Given the perceived range of advanced real-time systems as outlined in the introduction, there are many challenges ahead to lift the component technology from current capabilities to reaching the level of maturity of an engineering discipline.

Visions in Application Domains

Let us look into particular application domains to highlight the challenges.

The below paragraphs might be shortened

Within automotive industry, the recent mergers have further multiplied the number of platforms to be supported by car manufacturers. A vision for system development is that key functional "ingredients" of electronic control units (ECUs), sometimes called atoms or features, will be kept and maintained in a proprietary design repository, allowing model- and platform based variations to be constructed from such atoms using the above mentioned "drop & glue" approach. To support such a vision, component models must carry information for all system development processes: the system- design and possibly safety analysis process, for production and for maintenance. Let us consider concrete examples. To support power-management, component models must explicate operation modes which allow the system to be deactivated. To transition from an application independent model to deployment on a concrete network of ECUs, memory/CPU/bandwidth requirements of components must be known. Interfaces for diagnostic processes both integration testing, manufacturing, and maintenance must be visible. To support safety- analysis, component failure modes and failure rates must be accessible. These sample question highlight the need to maintain with each component an (application-specific) range of viewpoints, which jointly cover the life cycle of automotive applications. The elaboration of such an approach is further complicated by the need to support not only distributed development across multiple sites, but also various forms of interplay between manufactures and supplier companies, in particular allowing the integration of "atoms" from multiple sources (e.g. multiple suppliers) while protecting their IP. The need to ensure non-interference of such atoms when coming from multiple suppliers is obvious, taking into account legal issues such as liability. Hence strong encapsulation and rigid measures to assure this are a must in supporting component based design in this domain. It should be pointed that current industrial practice is far from this vision. We only begin to see today deployment of model-based development processes, and current methods and tool support are available for single ECU based implementations only. However, already the next generation development tools supporting distributed applications are in the pipeline, and companies are analyzing library based approaches.

The challenge for the telecommunication domain for the future is to enable the ubiquitous "anything, anytime, anywhere" concept. It means that a service should be seen for an end user as a black box respecting functional and non functional (Quality of Service) properties (or goals) independently of the underlying architecture. For that, we need innovative and consistent development methodology from high level specification towards design. Telecommunication applications, and similarly, new concepts such as VHE (Virtual Home Environment), are built from a set of service or service features (high level component), which could be new features but also existing features. Formal validation is necessary to obtain a consistent composition of such distributed components respecting their interface specification but also their properties as specified on the system view (user view for example). Real time aspects (performances for example) is also a critical problem, in particular, for the next mobile generation (UMTS), where quality of service is the subject of negotiation between the user terminal and the core network.

In factory automation the process of transformation from building monolith proprietary systems to component-based systems is already active several years. The process started from componentisation of applications in common platforms and additional components using software product-line approach. The second step, ongoing today, is decomposition of basic platform and further decomposition of different applications, using new component-based technologies, and mixing in-house developed components with COTS. These trends come from market requirements (reduced time-to-market, flexibility, lower development costs, and in the same time increase of Quality of Services, managing much larger amount of information, and finally integration with information and application from other domains). To be able to meet these requirements the automation industry is focusing on core-business, outsourcing, the reuse of components and buying COTS. However, there are many problems related to this approach that still remain to be solved, valid for component-based development in general and in particular in process automation (component technology, development processes, understanding system complexity, reliability of COTS and component-based systems, maintainability, flexibility, ability for integration, predictability of integration, trusted components etc.). A typical challenge of industrial process automation is integration. We can distinguish between vertical integration in which data and processes at different process levels are integrated, and horizontal integration in which similar types of data and processes from different domains are integrated. Typical examples of vertical and horizontal integration can be found in industrial process automation. At the lowest levels of management (Field Management), data collected from the process and controlled directly, is integrated on the plant level (Process Management), then is further processed for analysis and combination with data provided from the market and finally published on the Web (Business Management). To successfully obtain integration of different type of data and different type of application the integration process, as a part of the development process, must be seamless, reliable and predictive. Predictive integration is a challenge for itself. The main question of a predictive integration is if it is possible to predict the behaviour of component compositions from known behaviour of components (is. known functional and non-functional attributes). Automation industry is very well aware of advantages of component-based development approach, but also about the disadvantages. In many cases industry does not have solutions and is interested in finding them in collaboration with research.

CHALLENGES

The above visions of future component based technology can only be realized, if major technological challenges are met. Today, component technology is supported merely by syntactic definition of interfaces. It is a challenge to develop technology for semantic support, which includes the following challenges:.

OBJECTIVES

The objective of this action is to assess the current technical state of the art with respect to this vision, to identify scientific challenges for its realization. The action will be the result of collaboration between leading research teams with key competence on the foundations of the above topics. The action will rely on industrial guidance, as represented by an industrial advisory board involving key decision makers in different application domains.
It is important to relate the technology developments with emerging and new standards, such as promoted by the OMG or within STEP. Partners of the action, supported by the industrial advisory board, are in close contact with relevant bodies of standardization organizations, and will assess current and emerging standards wrt to their potential in supporting such a component design process. Example of questions to be analyzed are the aptness of UML and in particular RT UML in supporting the component technology vision of this action.

WORK DIRECTIONS

The challenges outlined above will be addressed along the following work directions:

TYPES OF ACTIVITIES

Interaction with Industrials An important part of the Work Package is to better understand the challenges and bottlenecks that face industrial practice. Interaction with strategically placed industrialists will be organized in the forms of interviews and seminars, and analysis of case studies. This task will be shared with WP1, Task 1.
Coordinator of industrial interviews: Jan Tretmans, Twente.

Workshops The work package brings together experience and expertise from different backgrounds. At least 3 meetings of the technical group will be organized annually, with invitations given to prominent industrialists and contributors with other relevant expertise. The meetings will be organized in connection with other major conference events, such as FLOC02, ACM/IFIP Middleware, ETAPS and UML Conference series, FTRTFT 2002, etc.

DELIVERABLES

The deliverables per year and task are as follows. The major technical deliverables are annual technical reports (white papers), which collects and synthesizes the experience and findings by partners in the activites outline above. The technical reports typically report on the state of the art, and outline directions for major research efforts.

Year 1:

Year 2:

Year 3:

BACKGROUND

The following technical areas are important for addressing the above challenges.

PARTNERS AND KEY PERSONS