Introduction
A component-based approach to software development is now emerging in the domain of embedded systems. This is notable – if not remarkable, given that the traditional approach to developing embedded applications has been driven by the primary goal of maximizing performance whilst absorbing the minimum of resources – memory (footprint), and power consumption (CPU). This approach is usually adopted by compromising software engineering productivity goals, such as reuse, and reduced complexity through modularization. However, even the most onerous class of embedded applications – those designed for deployment to Digital Signal Processor (DSP) devices, are now supported by productivity tools providing component models tailored to such devices.
The principal theme of the COMPARE project is the treatment of real-time requirements for embedded applications (RT/E) through the use of a standardized component model. This document presents the Vision for the COMPARE project.
Background
Underlying the evolution towards component-based middleware is the desire for software reuse. Reuse allows systems to be composed using previously developed building blocks that are designed to encapsulate a specific unit of functionality. In a component model, the component represents such a building block. Typically this provides application-level services to other components, exposed through clearly defined interfaces. Components execute inside a generic component server, or so-called container, that is created to run on a specific target platform, and provides system-level and management services to the components it hosts. The component model also defines component properties, dependencies between components, modes of access, and information in support of packaging, assembly and deployment.
From a functional design standpoint, a system is composed of interconnected components; from a configuration and deployment (non-functional) standpoint, different containers can manage components. Thus, the component-container model allows the definition of software units at a higher level of abstraction than allowed using conventional object-oriented programming models. This evolutionary step beyond object-oriented programming, extends the simple separation of interface and implementation, and is naturally adapted to circumstances where an application requires software units to be distributed across multiple devices.
Advantages of COMPARE 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.
|
COMPARE Vision 
