UPM Autonomous Systems Laboratory

The COMPARE Project

Component approach for real-time and embedded

2004-2006 / FP6-IST 004669

One general trend in software for real-time and embedded systems is towards complexity. This is due to the increased functionality these systems are required to support as well as to the fact that they are now often supposed to be part of a more general system and well-integrated in it.

The software architectures currently used to design those systems were primarily meant to take into account performance and limited resources management issues and are not enough structured to support this increase in complexity.

The challenge is thus to move from a performance-centric approach to a complexity-centric approach, while not losing in that move the adequate support for performance and time management. Traditional software had also to face this increase in complexity and had developed new paradigms to take it into account. A very promising one is the component/container model. However current models (e.g. Sun’s EJB, OMG’s CCM -CORBA Component Model) were primarily dedicated to information systems and the services they propose (e.g. persistence) are not well suited for real-time and embedded systems.

CORBA has moved towards real-time and embedded areas (cf. most of the recent adopted specifications); with the adopted Lightweight CCM, CCM has started a move in the same direction by defining a minimum profile upon which it is now possible to build a model dedicated to real-time and embedded.

The purpose of this project was to study a framework based on this model (CCM for real-time and embedded), to realize a reference implementation of it, to test it on two different application cases (one based on RT-CORBA, the second on OSEK-VDX RTOS) and to push the results at OMG for standardization.

We developed an engineering process and supporting tooling for RT system construction based on CCM-compliant components. In order to deal with separation of concerns, we focused on the provision of a modular and multi-purpose container which could be composed according to the needs of the application and host in this manner a number of real-time mechanisms. For that, a number of patterns for separation of concerns were analyzed, and the selected ones were used in the COMPARE container architecture.

Advantages of Componentized Technology

The advantages of using component-based technology in the RT/E domain, are founded in the core architecture of the component model, and are realized using various development and productivity tools specifically adapted to this class of application:

  • Portability: RT/E applications are developed for a wide diversity of operating systems (OS) and hardware platforms. One commonly adopted approach to providing more portable solutions is to incorporate an application layer that abstracts the required underlying platform functionality. Unfortunately, this approach presents particular difficulties when defining an API having common semantics across widely diverse architectures, in-that useful (often proprietary) function types needed to help support a particular business goal, may be unavailable on some supported platforms. The complexity of the abstraction layer will also increase with the diversity of platform support required, therefore the solution will not scale well when introducing new OS and hardware variants. The core abstractions in the component model on the other-hand, provides the opportunity to develop specialized (fit-for-purpose) containers, and allows the re-deployment of components from one RT/E device to another without the need for source-code modification.
  • Reusability: The reuse of software units within the scope of an organisation or collaborating parties is a practice known to increase cost-effectiveness in software development. However, in order to exploit such advantages, an appropriate level of granularity as necessary for the decomposition of application code into re-usable units needs to be identified. In an Object Oriented programming model, difficulties can arise due to the assumption that different entities in a software system/archive have interfaces that are amenable to inheritance and aggregation – also that these are written using same programming language. Thus, connecting large numbers of relatively homogeneous units using specialised coding conventions and styles can be error-prone and expensive. In a component model, formal definitions strengthen the visibility of component dependencies and therefore enforce rules for application assembly. This has the overall effect of minimizing ambiguity when selecting software units for re-use, thereby increasing cost-effectiveness in development, and reducing time-to-market.
  • Separation of Concerns: In conventional software development, there is often an inherent need to understand the broader issues associated with non-functional systems – enabling technologies, software integration, global system architecture etc. Domain experts therefore, can rarely invest their energy exclusively into the design development of business solutions. This problem is also exacerbated where the complexity of non-functional systems increases – as is the case with RT/E applications. Here, detailed (specialist) knowledge of non-functional systems is tightly coupled with application development concerns. The separation of concerns evident in the COMPARE approach provides the opportunity for domain experts to focus exclusively on the design development of business solutions, resulting in a more cost-effective use of development resources.
  • Visibility: Software development practices that re-use in-house coding styles – naming conventions, layout, modularization, and language specific productivity techniques, make it difficult for external parties to engage in collaborative development projects. Where new products are developed, this situation would likely impact to a greater extent on time-to-market. In a standards-based component model, coding styles/patterns are formally specified – usually public domain. This arrangement fosters cleaner integration, encourages closer partnerships between collaborating parties.
  • Quality in Development: When the use of conventional programming leads to the creation of monolithic systems, additional complexity is introduced into testing and validation systems. Consequently, these are relatively expensive to produce and are often not re-usable. The de-composition in component-model architectures, allows software units to be naturally isolated for testing and validation. This provides the opportunity to adopt an evolutionary approach to test development that can be integrated throughout the software development lifecycle.
  • Quality in Production: Strategies for self-management that ensure high system availability can be applied more systematically using components than with other more conventional systems. A component could for example, validate that an input value is within an acceptable range and provide a response that is non-intrusive to the component. Similar self-management strategies can improve system reliability by safeguarding component integrity in production.
The CMPARE Component/Container model.

Reference

Co7: Converging Trends in Complex Software-Intensive Control. R. Sanz. Sixth Portuguese Conference on Automatic Control. Jun. 2004.