This deliverable presents the results of initial
investigations into
- requirements for information processing
architectures for a class of embodied cognitive agents
described below
- requirements for tools to be used to implement such
architectures (including support for designing, testing
and debugging of implementations).
These requirements are discussed separately in Part
I and Part II so as to clarify the relationships between
what the tools are for, and what the tools should be.
Thus any evaluation of Part II needs to be done with
reference to Part I.
Likewise within Part I we separate out characterising,
in a preliminary and necessarily high-level way, what
sorts of functionality we are concerned with, from the
requirements for architectures that could provide that
functionality.
The kinds of functionality required are identified by
a class of scenarios involving fairly specific sorts of
behaviours in embodied cognitive agents, where the class
is specified by a scenario in which certain capabilities
are manifested by an advanced future domestic robot
(Fido) as sketched in the CoSy workplan Section 4. This
focus has a major influence on the detailed requirements.
For instance, different scenarios for robots or for
non-embodied, or non-mobile, intelligent systems, could
lead to very different requirements for architectures,
and to different requirements for tools.
However, many details are still left unspecified by
the Fido scenario, including the precise physical shape,
size and capabilities of the robot, and many of its
behavioural capabilities. So the scenario specification
leaves out important details which could affect the
requirements in ways that would have to be addressed in a
longer term study. The subset of behaviours we have
focused on most closely are those that relate to the two
main scenarios on which the CoSy team is working, the
Explorer and the PlayMate, described in deliverables
DR.10.1 and DR.10.2, although this
work package looks beyond the CoSy project, in order to
ensure the long term relevance of our work.
In the Fido scenario a robot performs typical domestic
tasks in a typical home, demonstrating competencies
involving interactions between many components of its
information-processing architecture -- tasks such as
navigating around a building, helping in a kitchen, and
interacting linguistically with humans and possibly other
robots. By analysing some of the detailed occurrences
within such performances we extract more detailed
requirements for the desired behaviours of the robot.
(Some of that analysis, based on the same class of
scenarios, is reported in DR.2.1 on
requirements for representations.)
Further analysis of the behaviours, including some
that are learnt and some pre-specified, how they cope
with a dynamically changing, partly unpredictable
environment (e.g. because of accidents and human
interventions), and how the behaviours might need to be
different in different contexts (e.g. dealing with an
adult vs dealing with a child, or coping with fragile vs
robust crockery) leads to a first-draft set of
requirements, including the requirement to support
multiple forms of representation, requirements to allow
various kinds of unplanned interactions between
sub-processes, requirements for multi-level control
mechanisms (e.g. attentional mechanisms) that help to
focus the available resources effectively, requirements
for self-understanding, and requirements for learning and
development.
These requirements present both a clear challenge to
the state-of-the-art of the design of information
processing architectures, and a contribution to a
development process which can later be refined into a
more detailed set of requirements as the work progresses.
However, past experience shows that many requirements
emerge only during the detailed design and implementation
processes, and even more only emerge during testing of
prototypes. So any set of requirements produced at this
stage must be tentative and incomplete.
Part II of this deliverable describes a broad set of
requirements for software tools that can be used to
implement a design for an architecture based on the
requirements presented in Part I. Examples of
requirements include support for a variety of programming
languages, flexibility of data exchange formats, and
support for reasoning about the connectivity of the whole
system. A variety of existing tools, both general and
specialised, are considered based on these requirements.
As with requirements for architectures, the full
requirements for tools will not be understood until we
are well into the project and have made substantial use
of an initial selection of tools.
The results of the analysis highlight two particular
areas of interest for any such collaborative project.
First, some requirements are extremely desirable in terms
of the functionality of a software tool (e.g. the ability
to form arbitrary connections between distributed
processes). Second, any tool chosen for use in the
project must allow the easy reuse of existing resources,
and must not prevent the use of developed code by members
of the research community beyond CoSy. These requirements
might not be the same as requirements in a large
commercial development organisation with strong central
management focused on producing only one project. Such an
organisation has far more control over its work-force
than an academic collaborative project. However we hope
that cross-fertilisation with other projects will
compensate for the need to cope with diverse preferences
and commitments.
