I-X: Technology for Intelligent Agents & Tools
Systems Architecture Overview
Work in Intelligent Planning and Activity Management at the University
of Edinburgh (See http://www.aiai.ed.ac.uk/project/plan/)
has led to a number of significant assets that are re-used on a number
of projects. These assets include: Nonlin, O-Plan, <I-N-OVA>,
Enterprise Ontology, Enterprise Architecture, Task Manager,
O-P3 Process Panels, Common Process Editor, etc. A new
generation of the work will drawn on this work, generalise it, and
significantly extend the application of the core concepts and assets,
leading to new re-usable components, and create opportunities for
applications and further research.
This new programme is called I-X and the core components are a
shared model representation called <I-N-CA> and a systems
integration architecture called I-Arch. A variety of re-usable
components and systems will be build on the new architecture and these
will be collectively referred to as I-Technology and
I-Arch is pronounced "Eye Arch". "Arch" stands for "architecture".
The "I" in I-X, I-Technology and I-Arch reflects the following:
I-Arch is a new systems integration architecture. Its design is based
on the O-Plan agent architecture. I-Arch incorporates components and
interface specifications which account for simplifications,
abstractions and clarifications in the O-Plan work. I-Arch provides
an issue-handling workflow style of architecture, with reasoning and
functional capabilities provided as plug-ins. Also via plug-ins it
allows for sophisticated management and use of the internal model
representations to reflect the application domain of the system being
buit in I-Arch. I-Arch agents may be recursively or fractally
composed, and may interwork with other processing cells or
architectures. This is a systems integration approach now being
advocated by a number of groups concerned with large scale,
long-lived, evolving and diverse systems integration issues.
- Intelligent - I-Arch supports the construction of intelligent systems
and intelligent agents
- Integration - I-Arch is a systems integration architecture
- Issue-based - I-Arch is an issue-based and issue handling architecture
The I-Technology programme has 5 aspects:
- Systems Integration - A broad vision of an open
architecture for the creation of intelligent systems for the synthesis
of a result or "product" which is based on a "two cycle" approach which
uses plug-in components to "handle issues" and to "manage and respect
the domain model".
- Representation - a core notion of the representation of a
product as a set of nodes making up the components of the product model, along
with constraints on the relationship between those nodes and a set of
outstanding issues - <I-N-CA> - Issues, Nodes, Critical
Constraints and Auxiliary Constraints.
- Reasoning - the provision of reusable reasoning and model
- Viewers & User Interfaces - to understand user roles in
performing activities and to provide generic modules which present the
state of the process they are engaged in, their relationships to
others and the status of the artifacts/products they are working
- Applications - work in various application sectors which
will seek to create generic approaches (I-Tools) for the
various types of Task in which users may engage.
We propose to bring together a number of threads of previous research
and development, and use state-of-the-art understanding of the
conceptual basis for flexible, incremental, mixed-initiative planning
and activity management systems. We will incorporate these into an
open, flexible, lightweight and embeddable system. This will be
written in Java for portability and to maximise reuse potential. The
core of the system will be an agenda-based issue handling system based
on workflow principles. It will be specialised to any particular task
by incorporating suitable issue-handling capabilities which could be
supplied by human or system components. It will be designed to allow
for very significant extension via an open capability plug-in
interface and via an interface to allow for the use of constraint
management methods, feasibility estimators, simulators, etc. The
system will be able to inter-work with other workflow and cooperative
working support systems, and will not make assumptions about the
internal architecture of those other systems.
The components of I-Arch are as follows:
- Task and Option Management
-- The capability to support user tasks via appropriate use of the
processing and information assets and to assist the user in
managing options being used within the model.
- Model Management
-- coordination of the capabilities/assets to represent, store,
retrieve, merge, translate, compare, correct, analyse, synthesise and
- Issue Handlers
-- Functional components (distinguished into those which
can add to the model (synthesis) and those which analyse the model (to
add information only).
- Constraint Managers
-- Components which assist in the maintenance of the consistency
of the model.
- Information Assets
-- Information storage and retrieval components.
-- User interface, visualisation and presentation viewers for the model -
sometimes differentiated into technical model views (charts, structure
diagrams, etc.) and world model views (simulations, animations, etc.)
-- Intermediaries or converters between the features of the model and
the interfaces of active components of the framework (such
as viewers, processing assets, constraint managers and information assets).
A number of different types of "sockets" are available within the
framework to reflect the protocols or interfaces into which the
various components can fit. The necessity for specific sockets and
the types of components vary across projects to some extent, but the
separation into viewers, processing assets, constraint managers and
information assets has been found to be useful in a number of AIAI
projects. This also puts the I-X work on a convergent path with other
Model/Viewer/Controller styles of systems framework.
The <I-N-CA> (Issues - Nodes - Critical/Auxiliary)
Model is a means to represent plans and other synthesised or designed
artifacts or products as a set of constraints. By having
a clear description of the different components within a synthesised
artifact, the model allows for them to be manipulated and used
separately from the environments in which they are generated.
I - Issues (Implied Constraints)
The positive node constraints (these are in the form ``include node'')
in the <I-N-CA> model set the space within which the description
of the artifact may be further constrained. The I (issues) and CA
constraints restrict the artifacts within that space which are valid.
If the product or artifact is an activity plan, some
types of ordering (temporal) and variable (object) constraints are
distinguished from all other auxiliary constraints since these act as
critical constraints or cross constraints, usually being
involved in describing the others -- such as in a resource constraint
which will often refer to objects/variables and to time points or
- which may add an "include node" constraint
N - Node Constraints
- which will not add an "include node" constraint
- include node constraints
C - Critical Constraints
- other node constraints
E.g., if the artifact is an activity plan:
A - Auxiliary Constraints
O - Critical Ordering Constraints
V - Critical Object or Variable Constraints
E.g., if the artifact is an activity plan:
O' - Non-critical Ordering Constraints
V' - Non-critical Object or Variable Constraints
X - eXtra constraints (such as):
- Authority Constraints
- World State Constraints
- Resource Constraints
- Spatial Constraints
- Miscellaneous Constraints
Addition needed here about "yes, no, maybe (in terms of critical
constraints)" responses from constraint managers.
Issues can be categorised as to whether
they will, may or will never add a "node".
The I constraints which can lead to
the inclusion of new nodes are of a different nature in the planning
process to those which cannot.
The choice of which constraints are considered critical is itself a
decision for an application of I-X and I-Arch. It is not
pre-determined for all applications. A temporal activity-based
planner would normally have objects/variable constraints (equality and
inequality of objects) and some temporal constraints (maybe just the
simple before(time-point1, time-point-2) constraint) as the critical
constraints. But, in a 3D design or a configuration application
object/variable and some other critical constraints (possibly spatial
constraints) might be chosen. It depends on the nature of what is
communicated between constraint managers in the application of the
The I-X approach involves the use of shared models for task directed
communication between human and computer agents who are jointly
exploring a range of alternative options for the synthesis of an
artifact such as a design or a plan.
A number of concepts are being used as the basis for exploring task
orientated multi-agent and mixed-initiative work involving users and
systems. Together these provide for a shared model of what
each agent can and is authorised to do and what those agents can act
upon. The concepts are:
- Shared Object/Product Model -- a structured representation
of the object being modelled or produced using a common constraint
model of the object or product (<I-N-CA>).
- Shared Planning and Activity Model -- a rich plan and
activity representation using a common constraint model of activity
(<I-N-OVA>, itself a specialisation of <I-N-CA>).
- Shared Task Model -- Mixed initiative model of "mutually
constraining the space of objects/products" - also using <I-N-OVA>.
- Shared Space of Options -- explicit option management.
- Shared Model of Agent Processing -- handlers for issues (functional
capabilities) and constraint managers - described using <I-N-OVA>.
- Shared Understanding of Authority -- management of the authority to
do work (to handle issues) and which may take into account options
and levels of abstraction of the model of the object or product.
In particular, this work will carry forward the development of a
strong systematic ontology to underpin the models of processes and
activity - including continuing to engage in and promote its use as a
basis for standards. The work will draw on the initial efforts to
create an ontology suitable for the conceptual description of all
apsects of an organisation - the Enterprise
Ontology and on the development of a constraint model of
activity <I-N-OVA>. The
work will promote the aim that PIF, NIST PSL, OMWG CPR and SPAR all
converge on a single core model of activity based on <I-N-CA>.
The initial areas of development under the I-X research programme include:
- Characterisation of the separate components of a single I-X agent
to establish what features each has and how they should differ. Establish whether the a priori view on the separate com pone ts is desirable.
- Initial Java encoding experiments to establish that the envisaged plug-in
framework is feasible and to experiment with different approaches.
- Consideration of how to describe plug-in components. This is
envisaged as being in the <I-N-CA> ontology, reified in Sorted
First Order Logic and storable in XML/RDF.
- The provision of an ontology for issues and issue handler descriptions
for some sample applications of I-X: (e.g. I-Plan, I-Config).
- A very simple initial application of I-X fully worked through
- A simple, but realistic application of a mainly man ual use of I-X
(user level process managment and collaboration support).
- A DERA-related sample application, possibly based on Coalition Operations.
- Other sample applications of I-X (e.g. I-Plan, I-Config).
- Consideration of how to describe the design, architecture and
implementation. Possible use of UML models.
Some issues to consider while refining the I-X and I-Arch design are
Other areas of study include:
- Java encoding limitations and opportunities
- Delivery of any user interfaces on multiple platforms via suitable web
- Use of XML/RDF to store intermediate results passed between
suitable agents and componen ts and to assist in storage of those
components in a form which can be retrieved and used.
- Design to allow for the resulting components to be repackaged and re-used
as embeddable components in a wide range of orther systems.
- Presentation (about product/artifact and process)
- Visible indications of users' workflow state
- Multiple views tailored to user role, information type, etc.
- Selection of what information to display.
- Views (e.g. tables) that facilitate comparison.
- Summary form with drill-down /expansion to details.
- TechWorld Viewers
- Colour-coding of status
- Colour choice principles
- Layout principles
- Multi-user cooperation
- User roles (as distinct from physical users)
- Issues (explicit representation and tracking of)
- Delivery (of applications, e.g. on Web)
- Standards (XML/RDF markup)
- Familiar interfaces (e.g. Browsers)
- Low bandwidth use (e.g. cellular phones, WAP, PDA)
- Reusable frameworks and modules
- Workflow of using the system itself
(hence meta-workflow in workflow tools)
- Process Issues
- An architecture / framework
- Plug-in concept and implementation support
- Plug-in Issue handlers, Artifact analysers, Constraint managers,
Motivation for I-X
Some factors which motivate the I-X work are:
- Human-friendly representations of plans for human communication
and cooperation, as well as man-machine interaction in areas such as
mixed initiative planning.
- Plan and activity representation ontologies and their potential
to assist in the knowledge acquisition and knowledge management process.
- Plan representations well suited to storage and for use in
markup languages such as XML.
- Plan representation languages which are also suitable for use to
represent the planning (task setting, planning, scheduling and
- Bringing AI plan and agent capability description experience into
- Relationship to emerging standards (NIST PSL, ISO, WfMC, etc).
Standards Efforts related to Plan Representations
A number of members of the AI plan representation research community
have been engaged over the last 4 years with colleagues interested in
process and plan representations fro manufacturing, e-commerce,
military, engineering, construction, aerospace and other uses. Some
of this work has led to shared interlinguas, ontologies and models
that have been used in practical work.
The DARPA sponsored Process Interchange Format (PIF) group, an Object
Model Working Group (OMWG) Core Plan Representation effort, the Shared
Planning and Activity Representation (SPAR) work and other efforts
have led to a high degree of commonality in the models adopted. The
National Institute for Standards and Technology (NIST) in the US
brought some of these threads of separate work together and created a
collaboration which has led to the Process Specification Language
[See http://www.nist.gov/psl/ for more
details of NIST PSL]. For references to this work, some of the
history and relationships between earlier work in AI on plan
representations and the standards bodies, and the part that \inova
played in this see Tate (1998).}. NIST PSL uses the PIF core model at
its heart and has a formally specified core semantics. <I-N-OVA> and
<I-N-CA> are compatible with the approach taken in the PIF Core and
therefore NIST PSL.
[This paragraph is a report provided in a personal
communication from Craig Schlenoff who led the NIST PSL program from its
inception through to February 2000.] In late 1999, at an International
Standards Organization (ISO), Technical Committee (TC) 184,
Subcommittee (SC) 4 standards meeting in Lillehammer, Norway, a
resolution proposing the Process Specification Language (PSL) work as
a Preliminary Work Item (PWI) was approved. The PWI is the first stage
of the standardization process, in which countries who are interested
in the work come together to further pursue the work. TC184 focuses on
industrial automation systems and integration while SC4 specifically
focuses on standardization of information which is shared or exchanged
in the area of industrial and manufacturing applications.
Page maintained by email@example.com,
Last updated: Thu May 29 15:49:02 2003