I-X: I-P2

Planning & Activity Management | I-X Home

Aim

To provide user level, configurable task and process management aids for inter-agent cooperation. Each user may have their own panel to reflect their role in a cooperative process.

Inputs for the Process Monitoring Panel

(communicable and storable via XML formats where appropriate)
  1. Requirement - requirements which external agents request that the process panel take responsiblity for. The sender may not know the authority relationship to the reciver, so cannot assume it will be acepted, and anyway, if accepted the receiver may not be able to satisfy the requirement. A requirement may be expressed in <I-N-C-A> form. This can have several elements which can be stated separately or may be given together.
  2. Report - reports of various kinds:
  3. Domain Model - which can include:
  4. Monitors - 0..N external event monitoring plug-ins to acquire externally communicated messages (e.g. as notified to agent message logging services). The plug-ins provide these events on an internal channel to be streamed in along with the explicitly notified report stream.
  5. Other - Process Panel designs beyond the monitoring aspects (e.g. for active process coordination and control) will be given other inputs related to other agent or process panel capabilities and constraints.

Process Panel Operations

A panel may be started up with a preloaded domain model, with issues it has been asked to address, with activities it has been asked to perform, and with constraints it has been asked to maintain.

Process specifications may include constraints/conditions (needed for monitoring aspects) and effects (needed for control aspects). These constraints and effects may be specified in terms of process product features (often the process product status note). Other constraints such as time, etc, may be provided. Process specifications may also include "effects" which specify changes which should be made to product features, etc.

Each process fragment that the panel knows about has an initial node which is specified as "enabled" or "not enabled". This may be altered at any time by a "process owner". A process must be enabled for an instance of it to begin execution. Once execution starts, that instance will continue until control returns to the initial node. If the process is not enabled at that stage, processing can be suspended. [Is this sufficient, or do we need preemptive termination of process instances for our work?]

The initial node of each process is "orange" (ready to execute) if the process is enabled, and red (not executable) if not enabled.

Process product features must include:

The process product features can also be extended to those features specific to given product types... [feature name . feature value]

Process panels only accept responsibility for issues or activities where there is a process that provides a capability to handle that issue or there are known external capabilities for other panels they can hand it to. But, they do not guarantee to be able to address the issue or perform the activity when it is processed. If requested, they will report the failure or achievement of the issue to the issue provider though.

Issues and activty requirements may contain information about the intended performer of an issue, or may leave that to the panel.

Issues are likely to have the following fields:

Activities have the usual full structure allowed within I-X systems.

Some ideas for a sample issue viewer (one of the I-Views) is here.

Issues may be a requirement to execute a specific process instance - execute(process, parameters).

The status of processes and process products may be tracked by using direc reports, agent activity logs and partial information which can be interpreted as indicating where we must be in one or more processes being executed, and what status process products must have at any stage. This can be done even where significant information is missing.

Issues that are addressed by I-P2 panels should have a priority. This could be as simple as low, medium and high, or could be very complex with separate features and criteria. It would be good to allow a panel user to change the priority from the 3 levels available.

The intention is that our generic approach to process and task management will allow the priorities of individual issues and activities to be stated when an issue or activity is first defined, or modified from agents outside the panel afterwards. We will also potentially allow the controller of I-P2 to be influenced by a prioritisation rules that themselves will be stated in terms shared with other agents and systems (communicated through a shared ontology of such priorities).

Planning & Activity Management | I-X
AIAI Page maintained by a.tate@ed.ac.uk, Last updated: Sat Mar 8 16:32:03 2008