Summary

Space4U Problem Statement

The general goal of Space4U is in line with the general goals of the ROBOCOP project, that is the definition of a component based software architecture for the middleware layer of high volume embedded appliances. High volume embedded appliances vary from cellular phones and personal digital assistants to internet and broadcast terminals like set top boxes, network gateways and digital television sets. Where the ROBOCOP project solves a number of critical issues like the enabling of software IP exchange and supporting (distributed) developments based on resource constrained, robust, reliable and manageable components, the Space4U project extends on this goals by including the awareness of the framework and its components with respect to Fault-, Power- and Terminal management related aspects. Besides these additional goals with respect to the ROBOCOP project the Space4U project will also continue to improve the maturity of the component framework and component model towards industrial use as well as to continue on the promotion towards the standards bodies.

Problem Domain

Software systems are continuously evolving; both during their development as well as during deployment. To cater for an increasing demand for flexibility, the Robocop architecture provides means for the dynamic replacement, removal and addition of components in a deployed system. This facility significantly complicates the terminal management task which we describe as follows:

Terminal Management is the set of activities aimed at maintaining integrity of the software that resides on a terminal and of the data used by this software

In the context of the Space4U project, a terminal is a high volume consumer device. Its management focuses on the period that a terminal is owned and used by a consumer. Integrity refers to functional aspects of the software inside a terminal but also to timing issues and resource use. E.g, after adding or replacing components into the component framework the terminal must remain working according to its specification. An example of the context we are thinking of is given in the following figure.

Specific Research Issues

Around this problem domain we envisage a few different issues. First, the architecture of the terminal should support the requirements discussed above. This calls for a new architecture that contains support for

1. maintaining a self-model of the system to reason about itself and to verify it against a preferred state;
2. dynamically evaluating non-functional properties like timing issues, memory use and energy requirements;
3. downloading content and new system components;
4. managing the terminal from a remote location.