I-X: Technology for Intelligent Agents & Tools
Scope | Introduction | I-Core | <I-N-C-A> | I-Model | I-PE | I-Plan | I-Config | I-Work | I-P2 | I-View | I-Spy | Work Area | Discsussion Group

Scope of Work

Work in Intelligent Planning and Activity Management at the University of Edinburgh 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 Panels, Common Process Editor, etc. A new generation of the work is now proposed which will significantly extend the application of the core concepts and assets, lead to new re-usable components, and create opportunities for applications. This new programme is called I-X and the core components are a systems integration architecture called I-Core and a shared model representation called <I-N-C-A>. 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-Tools.

The "I" in I-X, I-Technology, reflects the following:

I-X is a new systems integration architecture. Its design is based on the O-Plan agent architecture. I-X incorporates components and interface specifications which account for simplifications, abstractions and clarifications in the O-Plan work over the last 6 years under ARPI. I-X 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 of the internal model representations. I-X 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.

The I-Technology programme has 5 aspects:

  1. Systems Integration - A broad vision of an open architecture for the creation of intelligent systems based on a workflow process controller which uses plug-ins to handle "issues" and to manage the model of the product.
  2. 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-C-A> - Issues, Nodes, Constraints and Annotations. Engagement with various standards setting groups is a part of this work.
  3. Reasoning - the provision of reusable reasoning and model management capabilities.
  4. 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 with.
  5. 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. E.g.,
The work has Representation and Reasoning aspects:

Introduction

 The DARPA and AFRL Planning Initiative (ARPI) has sponsored work which has led to significant advances in planning and scheduling technology (Tate, 1996).

Striking advances have been made in the use of AI scheduling and constraint reasoning methods, which during ARPI have advanced from only being suited to toy problems to dealing with some of the largest problems that are likely to be required. The challenge problems and demonstrations domains used during ARPI have been ideally suited to demonstrating these advances as they are principally related to large scale asset scheduling (USTRANSCOM) or phasing (NEOs and ATO generation). These "back room" tasks are characterised by their relatively regular presentation and large scale - much as industrial job shop scheduling problems are.

Activity planning technology has also advanced very significantly during ARPI, and the engineering of such systems is now much better understood. However, the demonstration of this technology has not been seen as being so persuasive. Indeed, the types of activity planning demonstrations being shown within ARPI are at first sight simpler {Footnote: in fact there is a lot going on "under the hood" since mixed initiative is now possible, and greater levels of detail is possible in the activity models used.} than had already been shown in the mid 1970s and early 1980s by the pioneers of the first practical planning systems (STRIPS, NOAH, Nonlin, Deviser, MOLGEN, SIPE). At that time applications included robot control, engineer's apprentices, electricity turbine overhaul, Voyager spacecraft mission planning, molecular biology experiment planning, aircraft carrier operations, etc. Over the last few years activity planning technology has continued to achieve excellent results in the industrial (SIPE-2, Wilkins), engineering (OPTIMUM-AIV, Aarup et. al., Tate), governmental (Search and Rescue, Shadbolt and Tate; Oil Spill Management, Wilkins), military (KADET, Edwards) and entertainment (Bridge Baron, Nau) sectors. But little of these advances and successes has been brought to the fore in the demonstrations and challenge problems within ARPI. Why?

The nature of the successful applications of AI activity planning are different to and complementary with those achieved with AI scheduling and constraint management technology. The whole command, planning, scheduling, feasibility estimation, execution, monitoring, modification and control cycle needs a variety of techniques. Scheduling methods play an important and crucial role in the middle of this process. BUT, little attention has been paid to the arguably more important aspects of support to the commander or task and objectives assigner, the creative selection of the actual activities to perform (which are then scheduled in the available time, resource and spatial location), and the subsequent flexible use of the outline or skeletal plans to GUIDE the choice of activities to actually select, begin to enact, monitor and modify the activities performed as circumstances change. Little attention has been paid to the need to bring the PLANNING PROCESS under control and to improve the COORDINATION of the human and system agents in that process.

But this presents an opportunity to capitalise on the knowledge gained over the last few years and to make productive use of technology that to some extent has laid dormant for the last decade.

Over the last few years the importance of command centre coordination and workflow or process management has begun to be recognised. Commercial workflow systems are now available but deal with relatively simple repeatable processes. Improved cooperation environments have been provided (e.g. Collaborative Virtual Workspace, Mitre) but they are simple additional tools not well integrated into the work management of the user environment. Tieing these together is something that is recognised as a valuable goal (e.g. in ARPI's TIE 97-5 for the Genoa intelligence gathering process, MCC). TIE 97-1 under ARPI also made productive use of an user level process visualisation panel (ACP3, Tate et. al.) to communicate to a commander the status of the development of a range of alternative options as they were being explored by a wide range of planning and scheduling tools. The planning process being enacted in command and control centres is being explicitly modelled and brought under control in these experiments. There is an increasing realisation that flexible planning, resource management and coordination of the command, planning and control process lend themselves well to the use of advanced activity planning technology.

The interesting observation is that representation of the command, planning and control process is itself a very suitable type of application for activity planning technology. It demands knowledge-rich structures that relate intentions and objectives to activity by a large number of strongly differentiated agents and who have considerable scope for innovative activity selection. But the scale is also not too large. In fact, workflow and planning process planning is often somewhat smaller in scale than problems already tackled by activity planning systems. The combination of reasonable size, greater complexity of the domain model and variation in type of constraints, and of scope for choices between potential activities is a combination that stands out as being suitable for the application of proven activity planning technology.

Until recently there have been some technical stumbling blocks which have inhibited large scale deployment of planning technology.

  1. The lack of a shared model for activties and plans that could be communicated externally between users and systems and which would allow for import and export from specific system representations
  2. The lack of methods and tools to support the reliable modelling of domains in a way that could be readily maintained.
Both these areas are ones where considerable advances have been made in the last few years. Standardisation efforts in the computing industry (WfMC WPDL), engineering (PIF), business (Enterprise Ontology), military (CPR, SPAR and WarPlan), and in national standards (NIST PSL, PIF) has led to a large measure of agreement on the core entities which need to be exchanged. Formal underlying models for the shared ontology have been created (e.g., NIST PSL and Toronto TOVE) and translations to a uniform Sorted First Order Logic have been shown to provide benefits in communicating this information between planners and schedulers (Joslin, CIRL, Oregon; Polyak and Tate, Edinburgh). Languages and translators are now available and have been used on new start projects rather than people reinventing the wheel, as has occurred so much in the past. Importantly, these representations allow interchange of data with existing activity and business process modelling frameworks - such as IDEF. This addresses the other stumbling block - where does the domain model and plan/activity knowledge come from? The principles of knowledge engineering, software engineering and issue based design are being applied to ensure that domain models can be created. Initial libraries can be created from any existing models available by import, and may be used as skeletal plan fragments or activity templates as is. They can then be augmented with additional knowledge and constraints as necessary. New tool support and new methods to support activity modelling is now a new and growing research topic for US (E.g. AIPS-98) and European (ESPRIT PLANET network action area) researchers.

So, in short, the time is right to move to a new phase of rediscovering earlier planning technology and playing to its strengths, improving this in the light of the ARPI experience, and creating significant new assets that can be a basis for addressing new challenges and to create new opportunities.

I-Core

 To encourage asset re-use, the Institute has adopted a common systems integration framework or reference architecture for some of its projects. It is exploring multi-perspective domain modelling approaches based on shared underlying ontologies (fundamental characterisations of the entities and relationships in an application area).

Details of the I-X achitecture are available here.

The components are as follows:

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 AIAI's work on a convergent path with other Model/Viewer/Controller styles of systems framework.

I-Ontologies & <I-N-C-A> - Shared Models

The approach comprises:

I-Model - Multi-Perspective Modelling Approach

 AIAI has been using multiple perspective, multiple methods modelling methods for some time. It has done practical modelling work (e.g. on the ARPI ISAT Project Air Campaign Planning Process) using such methods. We have also used Multi-Perspective Approaches to reasoning about plans in the O-Plan work under ARPI. AIAI has used the terms Multi-Perspective Planning in the title of the most recent O-Plan project, and as a work package and technique name under the DARPA HPKB project.

Typical multiple perspective models have created a single ontologically underpinned model using our work on ontologies for processes and for enterprises and utilising several modelling methods from Europe (such as CommonKADS - itself combining a number of perspectives), the UK (such as Role/Activity Diagrams), and the USA (e.g., IDEF-3). Multiple-view or multiple perspective modelling is viewed in the software engineering and requirements capture communities as a valuable technique.

AIAI has been moving towards an approach to support modelling where we use a range of methods, and create a single shared model based on one or more small generic ontologies or conceptual models. The terminology in the model is anchored in a lexicon, which itself can be developed during modelling. Modelling support is provided by the creation of an agenda of outstanding modelling issues. These will eventually be able to be handled by seeking issue handlers which will select appropriate methods or tools to help the modeller address the outstanding issues.

Sample methods we have experience of are:

Sample ontologies we are using as targets for the models are: It should be noted that most of these are activity or process ontologies which reflects a main technical direction for AIAI in process and task management, or activity related task support.

Lexicons that are being used to anchor models have come from:

I-PE

The screen image shows Steve Polyak's <I-N-OVA> centred issue-based process editing environment - the Common Process Editor. This will be one of the sources of inputs for I-PE.

More details are here.

I-Plan

To be completed.

I-Config

To be completed.

I-P2

More details are here.

I-View

PlanWorld Viewers and Process Product Viewers. To be completed.

I-Work (aka I-Do)

The screen image here is from the agenda-based Task Manager from AIAI's Task Based Process Management project funded by EPSRC.

To be completed.

I-Spy: Areas of Study

AIAI Page maintained by a.tate@ed.ac.uk, Last updated: Thu May 29 15:48:42 2003