I-X: I-P2

Aim

Inputs for the Process Monitoring Panel

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.
   • "handle issue" requirements
   • "perform activity" requirements
   • "maintain constraint" requirements
   • "note annotation" information
2. Report - reports of various kinds:
   • "direct reports" - which may be agent messages providing inputs specifically informing the panel of some noteworthy events.
     • "progress reports" - useful information (before, during (or after) dealing with the item.
     • "completion reports" - indicating success or failure
   • "indirect reports" - via monitoring external sources of report information provided throiugh plug-ins (see below).
3. Domain Model - which can include:
   • 0..N process specifications/fragments - with related constraints/conditions, and issues for each process.
   • 0..N process product specifications - including descriptions of process product features.
   • [possibly 0..N process product status life cycle transitions. See Jessica Chen-Burger thesis and IBM's BSDM].
   • 0..N mappings from agent monitoring "events" notified explicitly or via plug-ins to the panel and:
     • begin of execution of a process node/activity
     • end of execution of a process node/activity
     • change in a process product feature
   • issue prioritisation rules to influence the controller.
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

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:

• Name
• Status (to reflect product life cycle)
• Content type
• Content [expressed as a URL?]

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:

• Sender Id
• Issue Id
• Issue priority
• Issue verb or function
• Issue contents (perhaps defined by a grammar)
  Short display format of contents perhaps deducable from grammar
• Annotations - first line being used for short display form
• 1..N methods by which the issue can be addressed

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

Page maintained by a.tate@ed.ac.uk, Last updated: Sat Mar 8 16:32:03 2008