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.
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.
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