Technical Report

Process Steps, Process Products, and System Capabilities

Brian Drabble, Terri Lydiard and Austin Tate

Approved for public release; distribution is unlimited

Artificial Intelligence Applications Institute University of Edinburgh 80 South Bridge Edinburgh EH1 1HN United Kingdom

April 14, 1997

ISAT-AIAI/TR/4 Version 2

Contents

1 Introduction 2

2 Knowledge Acquisition for the ACP Step Grammar 5 2.1 Overview of the ACP Knowledge Acquisition Process . . . . . . . . . . . . . . . . 6 2.2 Outcome of the Knowledge Acquisition Process . . . . . . . . . . . . . . . . . . . 6

3 ACP Process Management Steps Model 8 3.1 ACP Step Model Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 ACP Step Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 ACP Process Objects and Products Model 10 4.1 Process Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Process and Domain Levels in ACP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 ACP Process Product Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 ACP Verb Model 15 5.1 Overview of the Verb Model Development . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Outcome of the Verb Model Development . . . . . . . . . . . . . . . . . . . . . . 15

6 ACPT Tool Capabilities Model 18 6.1 Overview of the ACPT Tool Capabilities Model . . . . . . . . . . . . . . . . . . . 18

7 Summary and Future Work 20

Appendix A: ACP Process Management Steps 23

Appendix B: ACP Process Products 42

Appendix C: ACPT Tool Capabilities 50

Appendix D: ACP Activity Grammar 52

1 Introduction

The aim of this report is to describe a generic modelling framework being developed to represent the steps at the process management level of the Air Campaign Planning acp domain. ^{1} The process management level of the acp domain deals with the steps required to generate the air campaign plan e.g. “analyse target list”, “develop recommended jiptl”, etc. The main functions of the acp process are:

• the creation, use, modification and collation of the acp process products, e.g. orders, reports, documents, plans, letters, etc.

• the identification of the agent(s) (human and/or software) which have the capability to enact a step in the acp process.

A framework has already been developed which uses a simple grammar to describe the steps in the acp process and to act as a basis for describing the capabilities of tools and systems of an integration architecture to support acp. The three parts of the grammar are as follows:

• Verb: the activity to be carried out, e.g. analyse, develop, refine, etc;

• Noun Phrase: one or more noun phrases which describe the object(s) or process products on which the activity is being carried out, e.g. prioritised target list, tankering special instructions, etc;

• Qualifiers none, one or more qualifiers which constrain the way the activity is carried out e.g. time or resource limits.

The final aim of the research is to provide a mapping which shows the legal noun phrases and qualifier phrases which can be associated with each verb. Research has already been carried out to define a hierarchy of verbs [1] which can be used to describe the steps and a high level view of the capabilities of the acpt tools. This hierarchy has already been used by Dave Hess at saic to provide a way to define a database of capabilities of technologies being developed by darpa. Research has also been conducted [2] which aimed to identify a generic model for process products and their attributes which could be used to define the noun and qualifier phrases of the grammar. The research reported here aims to take this work further by identifying:

• the acp process products manipulated in a specific acp process step (defined by a specific verb). For example, the verb “refine” can be associated with the tankering special instruction but not the jfacc Guidance Letter.

• the features of the acp process products which are used as input conditions on the starting or termination of a process step. For example, weaponeering assessment can begin once a recommended jiptl is available but must not finish until it has been checked against an approved jiptl.

1This document corrects spelling errors found in version 1 issued December 17, 1996, and adds three subverbs to Organise (page 29). The models presented in version 1 are unchanged here.

• the type of a process product features, e.g. boolean, scalar, set, etc and the value associated with an attribute. For example, the boolean attribute availability can have either of two potential values: available and not-available.

By modelling the steps in the acp process level in terms of the process products they manipulate it becomes possible to more accurately reflect the way in which the acp process is carried out (e.g. the weaponeering assessment example mentioned above) and provide a way of mapping multiple alternative military planning domains to appropriate technologies. The final outcome of the modelling effort will be a model that captures the steps in the acp process, their input and output constraints e.g. the process products manipulated, temporal, resources and authorities in the acp domain.

The development process being adopted to describe the process level steps and the tool capabilities can be seen in Figure 1. The aim is to carry out further knowledge acquisition to identify the process products and their associated features and to use this information to refine the current tools and systems capabilities model, process products model and the verb hierarchy. The information will also be used to validate the simple grammar and to provide (where appropriate) suggestions as to possible changes that are needed. The outcome of the development process will be a series of updated models, an acp process description and the population of the grammar for the acp domain.

Figure 1: Overview of the Verb/Noun/Qualifier Identification Process

The structure of the remainder of the report is as follows, Section 2 describes the knowledge acquisition process which took place to identify the steps and process products in the acp process. Section 3 describes the model developed to represent the steps in the acp process and Section 4 describes the model for the process products identified. Section 5 provides details of the verb hierarchy used to describe the activities in the process steps and Section 6 describes how the model developed to describe the process steps can be used to describe the capabilities of agents (human and/or software) involved in the acp process. Section 7 provides a summary of the work to date and pointers to potential future work items.

A series of Appendices have been developed which provide addition information and show how the different models can be instantiated. Appendix A describes the steps in the acp process and Appendix B provides details of the acp process products. Appendix C provides details of the tool capabilities model and Appendix D describes the acp activity grammar which was used to describe the steps of the acp process.

2 Knowledge Acquisition for the ACP Step Grammar

This section describes the results of the knowledge acquisition process carried out to identify a mapping between the verbs, noun phrases and qualifiers used to describe the steps of the acp process. A series of meetings were held between 29th October and the 6th November 1996 with:

• checkmate: Major Mark Alred and Major Steve Cunico.

• saic: Dave Hess, Dale VanKirk, Chuck Freeman and Bill Sanns.

In common with other representations emerging from arpi technologies and acp modellers at various levels it is envisaged that the steps in the acp be described in the following form:

• Verb: describes the type of activity involved in the step, e.g. review, critique, issue, structure, etc.

• Noun Phrase(s): describes what the activity acts upon, e.g. document, report, tool, object, etc.

• Qualifier(s): describes additional information which restricts the tool in performing the task.

The same verb/noun(s)/qualifier(s) model can also be used to categorise the capabilities of agents (human and/or software) in tools such as acpt and jtf atd. Earlier research [1] developed a catergisation of verbs which grouped the verbs of the acp process in major and minor subgroups. Research has also been carried out into the process products which are created, modified, used and consumed by the steps in the acp process. The aims of the knowledge acquisition session were to identify:

1. the process products which could be associated with a given verb and/or qualifier. For example, the verb ”review” can be applied to a jfacc Guidance Letter but the verb ”critique” could not.

2. the potential classes of process products which could provide additional structure in the proposed grammar. For example, the candidate target list, target nominations list, service target nominations, jiptl and jiptl cut-off could all be classified as “lists of targets”. By identifying classes of process products with a verb rather than individual process products it becomes possible to create a more generic model of agent capabilities, e.g. O-Plan could be categorised as being able to refine all members of the class of target lists. Adding a new member to this class would not require the capabilities of individual agents to be updated. By building up this mapping it becomes possible to develop a grammar for describing the steps in the acp process.

3. the other constraints which are involved in each step in the acp process. The constraints are either:

• resource: these are the planning cell personal required to carry out the activity and include members of the intelligence group, combat planning cell, combat operations cell and the jfacc planning team.

• temporal: these are either qualitative, e.g. “the start of activity A precedes the start of activity B” or quantitative, e.g. “activity A must end no later than 16 hours after the start of conflict”.

• authorities: these describe specific authorities which must be obtained before an activity can start or finish, e.g. presidential authority must be given before the operation can begin.

The following subsections provide details of the models developed for the acp process and a summary of the outcome of the knowledge acquisition process.

2.1 Overview of the ACP Knowledge Acquisition Process

The knowledge acquisition sessions with checkmate and saic aimed to validate the approach of using a verb/noun(s)/qualifier(s) model for the activities in the acp process and the capabilities of the agents (human and/or software) in system integration architectures to support acp. Previous research had resulted in a verb classification hierarchy [1] which was used to develop simple models of the acp process activities and agent capabilities. The verbs were obtained from a series of idef and Commonkads models which were developed to provide an overview of the acp process and these models reflected the “as is” process being used by the usaf to develop the maap and ato. However, this process model does not reflect the use of acpt in the ato development process and the consequences of this which is to change the emphasis of the process from matching targets to objectives to refining strategies to tasks. In order to reflect the changes which acpt has brought about in the acp a new series of idef models were developed which represent a “transitive model” between the current “as is” model and the “to be” model. The “to be” model describes the acp process which the usaf aims to move towards and reflects a model in which there is no maap or ato generated and targets are developed on an as needed basis. The steps descriptions used in this document were taken from the “transitional” model and a full description of this model is provided in Appendix A. The “transitional” model is meant to provide a realistic model of the process within which a number of modelling and planning issues can be investigated and demonstrations constructed. It is not meant to be a truly accurate model of every aspect of the transitional model as this would require an extended number of knowledge acquisition sessions.

2.2 Outcome of the Knowledge Acquisition Process

This section describes the outcomes of the knowledge acquisition process and highlights areas in which problems were encountered in applying the verb/noun(s)/qualifier(s) model. The main outcome of the knowledge acquisition process were a series of step descriptions and agent capability statements described in terms of the proposed verb/noun(s)/qualifier(s) model. The process also identified a representative list of the process products used in the acp process. Details of the process products and In most cases it was reasonably easy to describe the activity in terms of the verb/noun(s)/qualifier(s) model. However, the process did identify a number of acp process steps^{2} which referred to objects in the domain but without associating it with a specific process product. For example steps such as “group targets” and “deconflict airspace” refer to objects in the air campaign domain rather than process products. Features of the acp domain such as airspace, targets, ground features, etc, exist in the real world and are not created by the acp process. It was possible to alter the steps description to explicitly identify the process products involved. For example, it was possible to describe. “deconflict airspace” as “deconflict airspace management requests” and “group targets” as “group targets of the candidate target list”. However, in the case of “deconflict airspace management requests” it was not certain that this truly reflected the way in which the step was carried out. For example, it is possible to deconflict the airspace by using a 3D model and tracing the entry and egress routes of the aircraft on the model. Thus it is possible to deconflict the airspace without making reference to the airspace management requests. For this reason it was decided to introduce a new class of objects to the model referred to as process objects. The distinction between process objects and process products is that process objects are not created by the acp process but can be used, modified and consumed in the same way as process products.

The knowledge acquisition process also highlighted the problem of identifying the effects an activity has on a process product. For example, the Joint Coordinated Targetting Board (jtcb) requires a recommended jiptl before it can start and produces an approved jiptl and a jiptl cut-off as an outcome. The jiptl cut-off contains those targets from the recommended jiptl which could not be attacked due to a limitation of resources, e.g. aircraft, bombs, missiles, etc. This activity could be modelled in two different ways.

1. The recommended jiptl is modified as the result of the jctb and changes its status to approved. The effect of the jtcb is to edit the recommended jiptl and remove those targets which cannot be attacked in this cycle of the ato. A new document referred to as the jiptl cut-off is created and contains those targets removed from the recommended jiptl.

2. The recommended jiptl is unchanged and two new documents are created i.e. an approved jiptl and a jiptl cut-off.

Further knowledge acquisition sessions are required to validate these modelling approaches and to identify those cases where each should be applied. The assumption made in the models being developed is that when a process product takes on a new process product feature value from a scalar process product feature e.g. the status transitions from recommended to approved, then the process product has been modified and not created a new. The information gathered during the knowledge acquisition process in contained in Appendices A and B.

2From this point the term acp model will refer to the “transition model”.

3 ACP Process Management Steps Model

This section describes the steps in the acp process and identifies their input and output constraints in terms of resource, time, authority, and process products manipulated.

3.1 ACP Step Model Description

The step model description provides details of the activities or steps in the acp process. The description focuses on the input and output constraints which are placed on the start and finish of a step. Previous research had produced a series of models using the Commonkads and idef-3 modelling methodologies. These models proved useful in providing background information and briefing materials on the acp process to members of the arpi. However, due to the modelling restrictions of these two methodologies information needed to more accurately reflect the workflow processes in the acp were missing. In particular information concerning the actual relationships between the start and finish of activities could not be represented. For example, both methodologies require activities to be linked from the finish of one activity to the start of another. However, in the acp process there are numerous examples, where activities can occur simultaneously or where one activity must start or finish after another. For example:

tanker operations planning can begin after the spins have begun but must not finish before the spins are complete. The tankering operations must be approved as part of the jiptl approvement process.

By only using simple finish to start links it is impossible to model this situation. Instead, a representation was needed which allowed for links to be placed between any end of an activity, i.e.

• start to finish

• start to start

• finish to start

• finish to finish

In addition to the problems caused by modelling inadequacies, it was difficult to reconcile the temporal information concerning start times and durations provided in [6] with the precedence links in the Commonkads and idef-3 models. On a number of occasions the time line information would show activities occurring in parallel whereas the Commonkads and idef-3 models would show them as a sequence. In order to resolve the problems an number of e-mail exchanges were undertaken between David Hess (saic), Anna Griffiths (isx), John McMillan and Larry Permenter (mitre) and Lt. Col. Hatchell (Air Combat Command). The outcome of the discussions were a series of changes to the idef-3 models which reconciled the problems in the different information sources.

The changes needed to support the workflow processes and to reconcile the temporal inconsistencies were then reflected in the models being developed to captures the transitional model of the acp process. This allowed a consistent and realistic workflow model of the acp process to be constructed. This model (together with the representation of process objects/products) was subsequently used as the basis of the O-Plan ifd qualifier experiments which showed how O-Plan could be used as a “planning to plan” support aid for the agenda of the nom controller of acpt. Full details of the idef-3 models is provided in Appendix A.

3.2 ACP Step Grammar

The acp step grammar defines a mapping between the verbs, noun phrases and qualifier phrases being used to model the activity steps in the acp process. The aim is to provide a framework within which activities and workflows can be defined for systems such as acpt, jtf atd and jfacc.

The verbs used to populate the grammar were identified from previous research and are described in Appendix A. The noun phrases comprise the process objects and products which are manipulated by the verbs. During the course of the knowledge acquisition process a number of different process objects or products were identified as being associated with a specific verb. For example, the verb refine was associated with the following process products:

• Target Nominations List

• Service Target Nominations

• jiptl

• jiptl Cut off

• Candidate Target List

The mapping between the verb and the process objects/products is not unique in that the same process object/product can be associated with a number of different verbs, e.g. the jiptl can be associated with assess, refine, approve, etc. However, for a number of process products is was possible to create a grouping and associate that group name with a verb. In the example, above, it was possible to create a process product group named “target list” and associate this with the verb refine. If further analysis of the acp domain reveals a distinction between the types of process product a verb can be associated then these groups can be subdivided. Alternatively sub-groups may be collapsed into a single group where they share a common number of attributes. The qualifier phrases comprise statements which alter the way in which the activity i.e. the verb is carried out. In a number of cases the qualifier was used to describe an adverb, e.g. Perform/Weaponeering-Assessment/Broad where Broad alter qualifies the amount of effort which should be carried out. In other cases the qualifier was used to specify a perspective which was to be used, e.g. Assess/ato/Quality Control which specifies the ato should be assessed against the quality control criteria and not cost, time, risk, etc.

Full details of the grammar and the process product groups can be found in Appendix D.

4 ACP Process Objects and Products Model

The section describes the process objects and products e.g. orders, documents, reports, letters, informal communications, etc, which are produced, used, modified or consumed by the steps in the Air Campaign Planning acp process. By modelling the steps in the acp process level in terms of the process objects or products they manipulate it becomes possible to more accurately reflect the way in which the acp process is carried out (e.g. the weaponeering assessment example mentioned above) and provides a way of mapping multiple appropriate technologies that can support tasks in the acp process. As described earlier a framework has developed which models the steps in the acp process using a simple grammar composed of verb/noun(s)/modifier(s) e.g. “Develop/Master Air Attack Plan/”, “Perform/Weaponeering Assessment/Broadly”, etc. The aim is to use the process objects or products and their features to populate the noun phrases and qualifiers of this model.

In order to identify the process products (and associated attributes) in the acp process a series of matrices were produced which show for each step in the acp domain the process products it creates, reads, updates and approves^{3}. This information was then used to identify a number of process product attributes (and their associated values) which were used to “trigger” the start or finish of the activity. This allowed the pertinent attributes and values to be identified and provided a base for the model of the process product attributes and values. A detailed description of the crua matrices and the attribute/value model developed for the process products can be found in Appendix B.

The following subsections provides details of the process object and products in the acp process and relates the acp process modelling described here to the other modelling efforts in the arpi. An overview of the attribute/value model is also provided which describes the structure of the model and the ways in which new attribute/values may be added.

4.1 Process Products

The process products in the acp process domain comprise the documents, reports, orders, letter, communications (formal or informal), etc which are used to represent the information present in the acp planning process. A process product may represent an intermediate result e.g. the draft tanker flows or may be the published document of the planning process e.g. the Air Tasking Order (ato). Each class of the process products has a number of features, the main one of which is the content (e.g. the acp plans themselves). Details of the relationship between the process products and the acp process are given in Figure 2.

In addition to its contents a process product may have many other attributes which are dependent on its class and use within the acp process. The different attributes are important in describing the way in which products are created, modified or used during the planning process.

While it may be convenient to model the acp process domain in terms of process products a number of occasions require reference to objects in the air campaign domain itself. Once such

3These are referred to as the crua matrices i.e. create, read, update and approve.

Figure 2: Process Products within the ACP Process

object is the “airspace” over the theatre of interest and may be referred to in activities such as Deconflict Airspace. To more conveniently model this aspects of the domain there are referred to as process objects and can be manipulated in the same way as process products except they cannot be produced. They can however be modified, used and consumed. For the remainder of this report it will be assumed that the two terms can be used interchangeable except where stated.

4.2 Process and Domain Levels in ACP

The terminology used for the military action related acp Plans themselves is confined to the contents of Process Products and is the subject of the acp Plans Model being developed by the arpi Plan Ontology Construction Group (pocg Cluster) [Hoebel, Valente, Q396]. Although the planning process involves activities and their coordination, these are described in terms of the activities which take place in the planning process itself (such as plan, change, review) rather than containing activities that relate to military effects (such as destroy, seek-out). The planning process activities can be described using a set of “process verbs” indicating the actions performed at the process level. A separate paper has been produced on the isat project giving an initial list of process verbs for the acp process [1]. A common underlying model of activity may be used for both the planning process and the acp plans themselves. In particular, the process products are modelled as resources which are created, modified and used within the process. Authority relationships and other conditions are also able to be modelled and may be used in an extension of the basic mechanism if that is wanted eventually. This is the subject of the pocg krsl-Plans ontology [Tate, Q295], the Process Interchange Format [pif Group, Q296] the omwg/jtf-atd Core Plan Representation [Q496], and the wider-scope Enterprise Ontology [Uschold, Q395].

Finally, all terminology used in each model will be available and defined in the ACP Domain Lexicon being built on the acp Sensus Ontology [Swartout, Q396]. Details of the different levels of process description in the acp are described in Figure 3.

Figure 3: Hierarchy of ACP Ontologies

4.3 ACP Process Product Modelling

A series of models of the acp process have been produced on the isat project using the Commonkads and idef-3 modelling methodologies[5]. Using the models as a base it was possible to identify the points^{4} process products in the acp process were being created, modified and consumed and more importantly where certain process products needed to have specific features. Further analysis of these models identified a number of problems due to the modelling inadequacies of Commonkads and idef-3. In particular is was not possible to correctly model the relationship between the “ends” (i.e a step’s start or finish) of two steps. It was therefore not possible to model:

tanker operations planning can begin after the spins planning has begun but must not end before the spins are complete and the jiptl has been approved.

A new series of models have been developed which more accurately model the step flow in the acp process domain and are reported in [4]. These models identify a number of process products, process product features and process product feature values. Examples of each of these are as follows:

• Process Products – jiptl

4The start or finish of a step in the acp process.

– ato

– aco

– Tankering spins

– Target Nominations List • Process Product Features

– Type

– Contents

– Contents Level

– Approval Status

• Process Product Feature Values – available

– not available

– draft

– rough

– potential

– proposed

– current

– on going

– cut off

– recommended

– approved

– unreleased

– released

Using the process product features identified from the crua matrices it was possible to group features into classes and associate with each class a descriptor type. For example, the features “available” and “not available” could be grouped together to form a single feature “availability” which can take one of these values. These features were used to form an ontology of primitive process product features which could in turn be used as the building blocks for more complex reasoning about the status of process products. For example, the status of the document could be (available, compound, published, draft). These would not be part of the primitive ontology of process products but would instead be composed of elements of the process products primitive ontology. In addition to identifying the features and values it was also necessary to identify the relationship between the potential values. This resulted in a series of relationships being defined for each features and the relationships identified are as follows:

• Boolean: The class can take one of two possible features. For example, a document can either be available or not available.

• Scalar:

The class can take one feature from a scalar set. For example, a document’s contents level can be either draft, conplan or oplan.

• Vector: The class can take a number of fixed features. For example, a document’s access information could be composed of a triple of modification operation, agent and date, e.g. (create, O-PLAN, 22:10:00).

• Set:

The class is a 0..N description composed of a number of sub-descriptors or classes. A document could have a status described in terms of:

– availability

– set of contents

– review status

– issue status

By grouping the features into named classes and identifying the relationship between its potential values it was possible to model the process products in the acp domain. The model has been validated through sessions with checkmate and was used as the base of the tools capabilities model an the acp activity grammar. Full details of the crua matrices and the process product model can be found in Appendix B.

5 ACP Verb Model

This section describes the verb model developed to model the activities of the acp process and the capabilities of the agents (human and/or software) in a systems integration architecture to support acp.

5.1 Overview of the Verb Model Development

The development of the verb model was motivated by the need to provide a way of describing system and technology capabilities and to initially populate an acpt process ontology which details the activities which take place in generating an air campaign plan, e.g. refine, issue, analyse, etc. This would compliment the domain ontology being defined for the acp plans which describes the activities in the plan itself, e.g. interrupt, destroy, paralyse, etc.

The need for a methodology to characterise the capabilities of systems and technologies was identified in a number of system integration environments, e.g. the Air Campaign Planning Tool (acpt) being developed by isx on behalf of the arpi, jfacc, and the jtf atd. The acpt has been developed to aid Air Operations Centre (aoc) staff in defining the objectives, task objects and targets of an air campaign. In common with other system integration architectures, acpt comprises a number of editors, viewers and reasoning systems (planners, schedulers, critiquers, etc) which are invoked by a user. At present the user is free to solve the problem in any order they wish as there is no prescriptive view imposed and the system itself does not provide any support in helping the user decide “what is the next best thing to do” from those problem solving issues outstanding.

Acting as a central focus to acpt is the Node and Objects Manager (nom) control panel. An aim for the mixed initiative planning framework (which it is proposed be added to acpt) is for the nom control panel systems, editors and viewers to be invoked with results written to the acpt database and further “issues” being put onto the nom’s agenda. The nom agenda will contain the issues which remain to be resolved before the plan is complete e.g. an objective specified at too high a level, missing steps (suppression of radars before attacking), etc. Each of these issues may be resolved by one or more tools or agents and in dealing with one issue several more issues may be added to the nom’s agenda.

5.2 Outcome of the Verb Model Development

The main emphasis of the modelling work was to identify the verbs involved in the acp process. This was accomplished in two phases. The first phase identified an initial set of verbs and the second phase refined the set of verbs by classifying two arpi technologies (and using other acp modelling sources). An overview of the verb identification process is shown in Figure 4. An outcome of the process has led to a way in which we can attempt to categorise other arpi technologies using the acp process verbs.

Full details of the analyses carried out in each phase of the verb identification process from both top down and bottom up perspective is described in a following sections.

ACP Verb Model 16 Figure 4: Overview of the Verb identification Process Each phase of the identification process used both top down and bottom up analysis techniques and a number of different information sources were used. It was expected from the outset that a modelling “gap” would be identified between the level at which the acp process was modelled and level at which capabilities of the systems and technologies were described (for example in acpt). One of the aims of the initial phase was to identify the extent of the gap and to propose a way of bridging it in terms of the verb/noun(s)/qualifier(s) model.

The results of phase 1 were that a modelling gap did exist and that a number of areas of the acp process were not currently covered by editors and tools in acpt. A set of verbs were identified and proposed as the outcome of phase 1 and these were used as the initial input to the phase 2 refinement process. The initial set of verbs was augmented and categorised by taking information from two further sources – The Joint Air Operations Force Level Planning models and the idef-3 models from the Theatre Battle Management Project. This refined verb model was then used to categorise two specific arpi systems, i.e. sri’s Sipe and isi’s expect. The results of the refinement process was the addition of a number of new verbs and the splitting/combining of a number of sub-verbs. The final part of the refinement phase was to take a different arpi system and attempt to describe its capabilities with the verb model. This was successfully achieved with the trains system from Rochester University. This was the first attempt to use the verbs classification on a system which was not part of the test cases, i.e. Sipe and expect. Full details of the analyses carried out in each phase of the verb identification process from both top down and bottom up perspective is described in [1] and details of the verb model can be found in Appendix A.

6 ACPT Tool Capabilities Model

This section describes the tool capabilities model developed to describe the capabilities of the agents (human and/or software) in the Air Campaign Planning Tool (acpt).

6.1 Overview of the ACPT Tool Capabilities Model

The aim of this analysis was to take the refined verb set and to use it to describe two arpi technologies, i.e. Sipe and expect. The initial set of verbs was used to initiate a series of discussions during which further verbs were added and others refined. For example, in the case of the expect system it was necessary to split the major verb Review into a series of sub-verbs which more accurately described the type of reviewing expect was carrying out. The sub-verbs of Review reflect a range of reviewing activities from “reviewing to learn” to “reviewing to critique”. However, a number of domain experts were unhappy with the choice of sub-verbs, in particular the choice of “review to critique” which they deemed to have a negative emphasis. One of the outcomes of the analysis was that certain verbs may be acceptable to the technology providers may be unacceptable to the domain experts.

The capabilities of the Sipe system were easier to categorise as they were similar to those of the O-Plan system being developed at Edinburgh which the authors of the report therefore understand. The main problem was understanding the meaning of the term “plan” and the different ways it could be interpreted as a capability in the domain. Plan could be interpreted in a range of ways such as “allocation of resources”, “build by construction” or “modify in a prescribed way” . One outcome of the analysis was that it was easier to describe the capabilities of the individual components of a planner than the capabilities of the entire system. A future aim of the study is to identify the major components of arpi systems and technologies and to categorise their capabilities as well. For example, the temporal network manager of the O-Plan system has the ability to manage temporal constraints which could be an advertised capability independent of O-Plan’s capabilities as a planner.

Full details of the final set of verbs used to describe Sipe and expect can be found in Appendix C.

An outcome of this work has been to suggest an initial approach to categorising arpi tools and technologies in terms of the acp process model (principally using the acp process verbs at this stage) [1]. The main parts of the approach are as follows:

• Classifying an arpi system or technology

• Refining the verb model

In addition to classifying the capabilities of an entire system or technology it may also be possible to categorise one or more of its sub-components, e.g. a knowledge acquisition tool kit, constraint manager in a planner/scheduler, etc. The same classification process should be followed to identify an appropriate verb/noun(s)/qualifier(s) description for each subcomponent of the system, One of the future aims of the work is to extend the model to include classes of noun and qualifier phrases which should be used. The contents of the noun and qualifier phrases will be based on the entries in process objects/products model and their associated attributes and values. Research at saic has already used the verb model to create a mapping between technologies being developed on different darpa programmes to the needs of the usaf. It is hoped to provide the revised capabilities model to saic in order to validate and refine the approach outside of the needs of the acpt. However, at present the scheme allows for any number of free format phrases to be specified. Full details of the tool capabilities model are provided in Appendix C.

7 Summary and Future Work

The section provides a summary of the research to date and pointers to further modelling work and potential extensions to the models. The modelling effort has resulted in three models of the acp process each which shows a different aspect of the domain.

• Process Steps Model:

This model provides a way of describing the steps of the acp process in terms of their input and output constraints. The model contains temporal, resource, authority and world state constraints which must be satisfied for the step to be executable. The model uses the same verb/noun(s)/qualifier(s) descriptors as are used in the capabilities model. In addition, details are also provided of the acp process grammar which can be used to associate a specific verb with a process object/product or class of process product.

• Process Object/Products Model: This model provides a way for describing the:

– process objects: targets, airspace, geographic features, etc, references in the acp domain.

– process products: documents, reports, orders, communications, letters, etc manipulated in the acp process.

together with their attributes and associated values. In addition the model provides details of the classes of process products e.g. target lists which occur in the acp domain.

• Capabilities Model:

This model provides a way for describing the capabilities of a number agents (human and/or software) which could be part of a systems integration architecture such as acpt. The capability descriptions are based on the verb/noun(s)/qualifier(s) model used to describe the steps of the acp process.

The models have been developed to the point at which they provide a realistic coverage of the acp process. The models have been validated by Major Mark Alred and Major Steve Conicu of checkmate and changes feedback into the models. The models themselves have been used for a series of qualifier experiments to show how O-Plan could be used as a “planning to plan” aid for the agenda of the nom controller of acpt.

The development of the models has revealed a number of interesting modelling issues and identified the need to extend the models in a number of specific ways. The aim is now to address these issues in four areas.

Process Product Classification

Further work is needed identifying the key process products and their attributes within the ACP process. There is still a substantial amount of work needed here especially on compound products which are a collation of other products, all of which exist in their own right.

An investigation is needed into the potential classification of process products so that product descriptions (in terms of their attributes and allowed values) can be made as generic as possible e.g. those process products which refer to target lists, e.g. ctl, tnl, jiptl, jiptl Cut off,. etc could be such a group. In addition we would like to relate the activities within the acp process, as described by the verbs in the Verb/Noun(s)/Qualifier(s) model, to the type of products they can operate on. If this relationship can be established the task of matching planning tool capabilities to process requirements may be linked to the type of products required as input or generated as output rather than to specific products.

Process Triggers

More detailed work is needed on identifying the events that trigger the start or finish of an activity processes such as acp. These events may be related to:

• temporal triggers which can be either qualitative e.g. A --> b or quantitative A must

     start 3 hours after B starts.

• authority triggers which allow an activity or resource to become available, e.g. the authority of centcom to release transport aircraft to the campaign.

• resource triggers which relate the the availability, release, or consumption of resources.

However, in very many cases the triggers will be related to the change in the value of a feature of a process product, e.g. a jiptl‘s status moving from recommended to approved. Although little effort has been put into their identification and definition, triggers on activities (and their subsequent processing by an agent) are a central issue to those developing process support for systems such as acpt, jtf-atd and jfacc. Systems such as acpt obtain information from a number of different servers, e.g. plan server, situation server, etc and will require a rich triggering language to inform them when the contents of these servers change. Further investigation of triggers could be based around a modified version of the crua matrix. While the current arpi project forms the focus for this proposed work it should be noted that these issues are central to the wider workflow community.

Complimenting the matrix idea we would use techniques similar to Task Hierarchy Diagrams (thd) developed as part of the Task Analysis process of the studio method. studio (Structured User Interface Design for Interaction Optimisation) was designed to aid in the production of high quality user interfaces but some of the techniques encompassed within it would seem applicable in the further analysis of the acp process.

thd is a form of Entity Life History and captures sequence, selection, iteration, parallelism and consequent behaviour of tasks, subtasks and abnormal tasks. Much of this this is not shown explicitly in the current idef methods or Commonkads models. thd provides a representation of the task decomposition of a process on as single diagram which is easily comprehensible to users of the information. Also the end-nodes of the decomposition process are clearly visible, and it is these that the modified crua matrix should use for its process trigger analysis.

Authority and Role Relationships

Some effort has already been devoted into the modelling of authority and role relationships but to date this has been minimal. In order to model the planning process more realistically and to provide support to potential workflow applications these relationships must be further explored. This would be particularly important in the work to move the acp process from a batch to a continuous one.

The purpose behind role activity modelling is to look beyond the activities which make up a process to the roles responsible for carrying out those activities. For the acp process we would be interested in producing clear definitions of the roles involved and in identifying required interactions between roles at each stage of the process. This will provide a way of clarifying how the approval mechanism for process products within the acp process in terms of who is involved, the stage of the process at which it occurs and the potential formats it may take, it will undoubtably help in the identification of the attributes of the process products themselves.

Timing Information

The representation of temporal information within the acp process has not been properly addressed. Although many groups have modelled different aspects of the process no single group has come up with a satisfactory and consistent method for indicating timing constraints. This area should be investigated as it is envisaged that it will become important in supporting the transition of acp from a batch process to a more continuous one.

Appendix A: ACPT Process Management Steps

A.1: IDEF-3 ACP Process Models

This appendix describes the idef-3 process models which were developed to capture the transitional acp process. The transitional model reflects the changes which acpt has brought about in the acp process i.e. the move from associating targets to objects, to elaborating strategies to tasks. The models have concentrated on the section of the acp process which deals with the refining of objectives through to the development of the Master Air Attack Plan (maap). Details of the subsequent generation of the ato and support missions have not been included.

Figure 5: Joint Air Operations Force Level Planning

Figure 6: Plan Joint Air Operations

Figure 7: Develop JFACC Guidance

Figure 8: Develop Targets

Figure 9: Develop Candidate Target List Figure 10: Develop Draft JIPTL Figure 11: Provide Weaponeering Assessment Summary and Future Work 25

Figure 12: Develop Target Products

A.2: ACP Verb Descriptions

This appendix describes the verb classification hierarchy used to describe the activities of the acp process and provide a base for describing the capabilities of the agents (human and/or software) in the acpt. Each major verb is split into a number of sub-verbs which describe a specific aspect of the major verb. In a number of occasions a number of major verbs share one or more sub-verbs and this is indicated by a pointer to the other major verb. For example establish is a sub-verb of both Analyse and Obtain. Associated with each major verb are a series of notes which indicate the type of activity it should be associated with. Where two or more sub-verbs are separated by commas this indicates that the verbs are synonyms of each other. Details on the development of the verb model and the methodology to extend and refine it can be found in [1].

Major Verb: Analyse

• Notes: ANALYSE has notion of quantitative investigation

• Sub-Verbs

– predict – foretell a future state of situation

– determine – resolve or define an outcome

– monitor – watch, check or supervise

– diagnose – ascertain from symptoms

– establish (see OBTAIN) – set up a situation

– measure – to ascertain dimensions or amount

Major Verb: Assess

• Notes: Assess has a notion of qualitative investigation and is similar to “grade” in CommonKADS.

• Sub-Verb

– estimate – judge the worth of, reckon the value of by rough estimation

– expect – to suppose or wait

– consider – to take into account or deliberate on

– ascertain – to prove

– determine (see ANALYSE)

– evaluate – judge the value of an item against a predefined set of criteria

Major Verb: Assign

• Notes: This has the notion of both authority and the “handing over” of a resource or responsibility.

• Sub-Verbs – allocate, staff – assign one or more objects to an item

– apportion – share out amongst one or more groups

– delegate – commit authority to a group or person

Major Verb: Communicate

• Notes: This is the communications which takes place agents (user or systems) within the planning process.

• Sub-Verbs – request – petition or ask a third person or group

– acknowledge – announce receipt of an object

– reject – put aside or return object

Major Verb: Decide

• Notes: some of the meanings of DECIDE imply finality (finalise, terminate), others seem to imply select by consideration (approve, calculate). Not sure how make certain fits in (confirm/match/compare ?)

• Sub-Verb – complete, finalise – finish of define as having maximal extent

– approve (see REVIEW) – sanction or commit

– terminate – bring to an end (not necessarily complete)

– choose – select from a greater set

Major Verb: Develop

• Notes: This has the sense of growth or production of an artifact. The term “plan” is used in the joac model. On analysis of the joac model it was found that it was being used in that particular context as a creation activity and could therefore be replaced by produce or create.

• Sub-Verb – build, construct – construct by putting parts together – produce, create – bring or cause to come into existence

– compose – arrange in a specified or understood order

– prepare – make ready to a required point

Major Verb: Identify

• Notes: IDENTIFY has notion of set manipulation, all the meanings given could be

further defined in terms of set manipulation; – select by consideration – pick from a set according to various criteria

– compare – match ?

– resemble– match/compare?

– detect – merge/combine items to form a set

• Sub-Verb – classify, group – to fall into harmonious combinations

– match – to be equal to or comparable with

– select by consideration – to pick from a set by preference

– compare, resemble – to liken or represent as similar to

– detect – to discover to find our

Major Verb: Issue

• Notes: There are various types of response implicit in the type of issue raised: – ISSUE (circulate) has notion of report-back

– ISSUE (emerge/flow/be driven from/supply) has notion of create

– ISSUE (publish) has notion of making available

– ISSUE (release)

– ISSUE (give out orders to subordinates)

• Sub-Verb

– release – to make available (has less formal meaning that publish and distribution is controlled)

– deliver – to give up or discharge

– publish – to send forth to the public

– transmit – to send on, communicate

– circulate – to move around and spread further

Major Verb: Modify

• Notes: Modify has the notion that one or more objects should be changed in a prescribed way.

• Sub-Verb – combine, join, link – unite or be brought together for a common purpose – refine – remove defects and clarify

– integrate – complete by the addition of parts

– evolve – deduce further information or extent

– augment – make or become greater than original

Major Verb: Obtain

• Notes

• Sub-Verb – receive – accept delivery of

– acquire – gain possession of

– establish – secure permanent acceptance of

Major Verb: Organise

• Notes: ORGANISE has notion of managing and or creating a structure:

• Sub-Verb – co-ordinate – cause to function together or in proper order

– regularise – put into a consistent structure

– formalise – give definite shape to

– deconflict – remove constraint violations between one or more objects – phase – group items along a specified time line

– sequence – order items along a specified time line

– plan – identify and order activities according to specified constraints

Major Verb: Perform

• Notes: PERFORM has the notion that the activity or role is carried out.

• Sub-Verb – execute – carry out required activity

Major Verb: Prioritise

• Notes: PRIORITISE has the notion that you are ordering objects in relation to some criteria: precedence, time, seniority, importance, rank.

• Sub-Verb

– order – put into a prescribed sequence

– rank – associate to a prescribed grade

Major Verb: Provide

• Notes: PROVIDE has the notion that you are giving something to a third party which may be physical or not.

• Sub-Verb

– supply, furnish – provide a needed resource (occurring over an extended period)

– equip – provide requirements needed (start up. setting up a position)

– offer – readiness to provide assistance

– give – transfer to a third party usually as a gift

– input – make a contribution to

Major Verb: Review

• Notes: (see ASSESS/evaluate). This has a notion of finding out information which is then used for a number of other activities, e.g. review to learn, review to critique, etc.

• Sub-Verb

– learn – gain understanding of situation or artifact

– appraise – estimate the value of

– summarise – ascertain the key elements of an object or situation

– critique – identify major flaws and suggest remedies

Major Verb: SUPPORT

• Notes: This has the notion that you are providing some level of effort to improve the position of a third party.

• Sub-Verb:

– sustain – provide resources over an extended period

– strengthen – make a position or situation stronger

– approve – confirm or show satisfaction with an approach

A.3: ACP Step Descriptions

This appendix describes each of the steps in the acp process management. Each step describes:

• The name of the activity step.

• idef0 model reference number.

• The agents (human and/or software) which are required to support the execution of the step.

• The process products which are created, read, updated or authorised by the step.

• The temporal, resource and authority constraints imposed on the start and finish of the step.

• A textual description of the step and references to any other relevant materials.

Each of the steps in the acp process are as follows:

• 1: Plan Joint Air Operations

– idef0 ref: A3

– Agents:

– Process Products:

– Constraints:

– Description:

These diagrams are based on the IDEF0 diagrams in the document ”Joint Air Operations Force Level Planning” by David Hess, knowledge acquisition session with checkmate, and a modeling workshop with David Hess at SAIC, Hampton. References to the matching IDEF0 processes are given on the IDEF3 UoBs (bottom right hand corner) with details of differences given in the elaboration boxes.

• 1.1.2: Develop JFACC Guidance

– idef0 ref: A31,A32

– Agents:

– Process Products:

– Constraints:

– Description:

”Develop JFACC Guidance” encompasses both ”Staff Courses of Action” (A31) and ”Provide JFACC Guidance” (A32) from the IDEF0 models. This activity closely mirrors the IDEF0 process ”Provide JFACC Guidance” (A32) b ut has been modified to reflect the introduction of ACPT and ”Strategies-to-Task ” process. ACPT develops linked strategies-to-tasks. Tasks derive their priorities and sequencing from the strategies, along with their measures of merit.

• 1.1.3: Develop Draft Support Plans – idef0 ref: A34

– Agents:

– Process Products:

– Constraints:

– Description:

The positioning of this activity within the ACP planning process is the first major differences between the transitional model and the as-is model. Here development of the majority of the support plans are carried out in advance of target development. In the IDEF0 model this is done by activities A341, A342, A343 and A344. These plans are finalised at the detailed planning level which is carried out after the development of the MAAP, along with reacting to any specific support requests. This step is outside the boundaries of interest for this work.

• 1.1.4: Develop Targets – idef0 ref: A33

– Agents:

– Process Products:

– Constraints:

– Description:

The ordering of the subactivities within this activity reflect the second major change between the transitional and the as-is model. Again these changes have been introduced through the introduction of ACPT. The sub-activities themselves are unchanged, just their ordering is different.

• 1.1.5:Finalise Support Plans – idef0 ref: A345

– Agents:

– Process Products:

– Constraints:

– Description:

Mirrors the activities in A345 ”Integrate Detailed Air Planning” and probably includes some of the finalising support details from the previous steps A341, A342, A343 and a A344. This step is outside the boundaries of interest for this work.

• 1.1.6: Publish Orders – idef0 ref: A35

– Agents:

– Process Products:

– Constraints:

– Description:

Reflects the IDEF0 process, and is outside the boundaries of interest for this work.

• 2.1.7: Prioritise Objectives to Tasks – idef0 ref:

– Agents:

– Process Products:

– Constraints:

– Description:

• 2.1.8: Sequence Objectives to Tasks – idef0 ref:

– Agents:

– Process Products:

– Constraints:

– Description:

• 2.1.9: Phase Tasks – idef0 ref:

– Agents:

– Process Products:

– Constraints:

– Description:

• 4.1.10: Develop Candidate Target List – idef0 ref: A331

– Agents:

– Process Products:

– Constraints:

– Description:

The Candidate Target List (CTL) is called the JFACC Target Nominations in the IDEF0 diagrams. It is within the subactivities of this step that the second major change between the transitional and as-is model can be seen. In the as-is model there is a direct link between targets and JTF objectives, but the introduction of ACPT links targets to tasks. Targets derive their priority from the tasks they are linked to. Traditional Target Systems Analysis (A3312, A3313) has been moved after the selection of targets (A3314). However this work is undertaken on a more iterative basis than at a set stage in the process

• 4.1.11: Develop Draft JIPTL – idef0 ref: A332

– Agents:

– Process Products:

– Constraints:

– Description:

The draft JIPTL is that which is formed by integrating the Target Nomination Lists (TNL) from the component commanders and which is sent up to the JFACC for recommendation. This activity mirrors that described in the IDEF0 process ”Develop Draft JIPTL” (A332) with the added note that in subprocess Prioritize Joint Air Targets (A3324) the priorities for the targets are derived from the task relationships.

• 4.1.12: Provide Weaponeering Assessment – idef0 ref: A333

– Agents:

– Process Products:

– Constraints:

– Description:

This activity mirrors the IDEF0 process ”Provide Weaponeering Assessment” (A333) unchanged.

• 4.1.13: Develop Target Products – idef0 ref: A334

– Agents:

– Process Products:

– Constraints:

– Description:

This activity mirrors that of the IDEF0 process ”Develop Target Products” (A334) unchanged.

• 10.1.14:Assign Targets to Tasks – idef0 ref:

– Agents:

– Process Products:

– Constraints:

– Description:

• 10.1.15: Select Targets

– idef0 ref: A3314

– Agents:

Agent: Communication Devices

Agent: Intelligence Specialists

Agent: Target Database System

Agent: Target Planning Tools

Agent: Target/Weaponeering Experts

– Process Products:

∗ Creates: Initial JFACC Target List/CTL, Recommendation for ROE Modification, Recommended Changes to JTL, Request For Additional Guidance, Request for LOAC Interpretation.

∗ Reads: Fallout Targets, Previous Plans

– Constraints:

Procedure, JFACC Guidance, Critical Nodes/Elements, JTL, ROE, LOAC

– Description:

• 10.1.16: Link Targets to Target Sets

– idef0 ref: A3312

– Agents:

Agent: Communication Devices

Agent: Intelligence Specialists

Agent: Target Database System

Agent: Target Planning Tools

Agent: Target/Weaponeering Experts

– Process Products:

∗ Updates: Existing Target Sets

∗ Creates: Request for Intelligence

– Constraints: Procedure - Functional Connection, JFACC Guidance, External Environment

– Description:

• 10.1.17: Identnify Critical Nodes/Elements

– idef0 ref: A3313 – Agents:

Agent: Communication Devices Agent: Intelligence Specialists Agent: Target Database System Agent: Target Planning Tools Agent: Target/Weaponeering Experts

– Process Products:

∗ Creates: Critical Nodes/Elements,Request for Intelligence

– Constraints: Procedure - Physical and logical Connection - historical Precedence, JFACC Guidance, External Environment

– Description:

• 10.1.18: Assess Target Vulnerability

– idef0 ref: A3315

– Agents:

Agent: Communication Devices Agent: Intelligence Specialists Agent: Target Database System Agent: Target Planning Tools Agent: Target/Weaponeering Experts

– Process Products:

∗ Creates: JFACC JIPTL Target Candidates

– Constraints: Procedure, JFACC Guidance, Combat Assessment, Assessments, External Environments

– Description:

• 10.1.19: Select Functional Damage Criteria

– idef0 ref: A3316

– Agents:

Agent: Communication Devices Agent: Intelligence Specialists Agent: Target Database System Agent: Target Planning Tools Agent: Target/Weaponeering Experts

– Process Products:

∗ Creates: JFACC JIPTL Target Candidates with Functional Damage Criteria ∗ Reads: JFACC JIPTL Target Candidates

– Constraints: Procedure, JFACC Guidance, Targeting Objectives, ROE, LOAC

– Description:

• 10.1.20: Match Damage Criteria to Task MOM

– idef0 ref:

– Agents:

– Process Products:

– Constraints:

– Description:

• 10.1.21: Analyze Intelligence/Target Information

– idef0 ref: A3311

– Agents:

Agent: Communication Devices

Agent: Intelligence Specialists

Agent: Target Database System

Agent: Target Planning Tools

Agent: Target/Weaponeering Experts

– Process Products:

∗ Creates: Request for Intelligence

∗ Reads: Integrated Database

– Constraints: Procedure, JFACC Guidance, Targeting Objectives, Combat Assessment, Assessments

– Description:

Not sure this one still happens. Check with Dave Hess

• 11.1.22: Evaluate Joint Air Targets

– idef0 ref: A3321

– Agents:

Agent: Targeting/Weaponeering Experts

Agent: Communication Devices

Agent: Liaisons

Agent: JAG

Agent: Planning Tools

– Process Products:

∗ Creates: Request for Intelligence, Target Information Request, Evaluated Joint Air Targets – Constraints: JTL, Intelligence Information, Higher Echelon Guidance, JFC Di-

rected Targets, ROE, LOAC, Combat Assessments, Procedure, External Environment, Schedules

– Description:

• 11.1.23: Deconflict Joint Air Targets

– idef0 ref: A3322

– Agents:

Agent: Targeting/Weaponeering Experts Agent: Communication Devices Agent: Liaisons Agent: JAG Agent: Planning Tools Agent: Planners

– Process Products:

∗ Creates: Component Target Coordination Feedback, Deconflicted Joint Air Targets

∗ Reads: Evaluated Joint Air Targets, Component Plans, Special Asset Response – Constraints: JFACC Guidance, External Environment, Higher Echelon Guidance,

ROE, LOAC, Combat Assessments

– Description:

• 11.1.24: Develop Special Asset Requests

– idef0 ref: A3323

– Agents:

Agent: Targeting/Weaponeering Experts Agent: Communication Devices Agent: Liaisons Agent: JAG Agent: Planning Tools Agent: Planners

– Process Products:

∗ Creates: Special Asset Request

∗ Updates: Component Target Coordination Feedback

∗ Reads: Deconflicted Joint Air Targets, Component Plans, Special Asset Re-

sponse

– Constraints: JFACC Guidance, External Environment, Procedure, Higher Echelon Guidance, ROE, LOAC, Combat Assessments

– Description:

• 11.1.25: Prioritize Joint Air Targets

– idef0 ref: A3324

– Agents:

Agent: Communication Devices Agent: Liaisons Agent: Planners Agent: JFACC

– Process Products:

∗ Creates: Draft JIPTL

∗ Updates: Component Target Coordination Feedback

∗ Reads: Special Asset Request, Deconflicted Joint Air Targets, Component

Plans, Special Asset Response

– Constraints: JFACC Guidance, Schedules, Procedure, Higher Echelon Guidance, Combat Assessments

– Description:

• 12.1.26: Review Target Graphics

– idef0 ref: A3331

– Agents:

Agent: Graphics Tools Agent: Target Planning Tools Agent: Liaisons Agent: Target/Weaponeering Experts

– Process Products:

∗ Creates: Request for Intelligence, Request for Additional Guidance, Mensurated Coordinates

∗ Reads: Graphics Response, Graphics Database, Request for Mensurated Coor-

dinates, Request for Target Element Measurements

– Constraints: Target System Assessments, Draft JIPTL, JIPTL, JFACC Guidance, Schedules, External Environment

– Description:

• 12.1.27: Determine DMPI Options

– idef0 ref: A3332

– Agents:

Agent: Target Planning Tools Agent: Liaisons Agent: Target/Weaponeering Experts Agent: Communication Devices Agent: JMEM Methodologies – Process Products:

∗ Creates: DMPI Options, Target Element Vulnerability Estimates, Request for Intelligence, Request for Additional Guidance, Request for Target Element Measurements, Request for Mensurated Coordinates

∗ Reads: Weaponeering Options, Mensurated Coordinates

– Constraints: Target System Assessments, JIPTL, Schedules, External Environment, LOAC, ROE, Functional Damage Criteria

– Description:

• 12.1.28:Determine Weaponeering Options

– idef0 ref: A3333

– Agents:

Agent: Target Planning Tools Agent: Liaisons Agent: Target/Weaponeering Experts Agent: Communication Devices Agent: JMEM Methodologies

– Process Products:

∗ Creates: Request for Additional Guidance, Recommendation for New/Additional Weapon Systems, Weaponeering Options

∗ Reads Request for Mensurated Coordinates, Request for Target Element Measurements, Mensurated Coordinates, DMPI Options, Target Element Vulnerability Estimates

– Constraints: Draft JIPTL, JIPTL, JFACC Guidance, Schedules, External Environment, LOAC, ROE, Functional Damage Criteria

– Description:

• 12.1.29: Select DMPI with Valid Weapon System Options

– idef0 ref: A3334

– Agents:

Agent: Target Planning Tools Agent: Liaisons Agent: Target/Weaponeering Experts Agent: Communication Devices Agent: JMEM Methodologies

– Process Products:

∗ Creates: Recommendation for New/Additional Weapon Systems, DMPI With Recommended Weapons Systems

∗ Reads: DMPI Options, Target Element Vulnerability Estimates, Weaponeering Options – Constraints: Draft JIPTL, JIPTL, JFACC Guidance, Schedules, External Envi-

ronment, LOAC, ROE, Functional Damage Criteria, Available Assets

– Description:

• 13.1.30: Build JTCB Target Briefing

– idef0 ref: A3341

– Agents:

Agent: JFACC Agent: Planners Agent: Communication Devices Agent: Targeting/Weaponeering Experts Agent: Liaisons Agent: Target Planning Tools

– Process Products:

∗ Creates: JTCB Briefing

∗ Reads: DMPI With Recommended Weapons Systems, Recommendation for New/Additional Weapon Systems, Recommended Changes to JTL, Draft JIPTL

– Constraints: LOAC, ROE, JFACC Guidance, Schedules, Assessments, Enemy Assessments

– Description:

• 13.1.31: Build Target Chart Overlay

– idef0 ref: A3342

– Agents:

Agent: Communication Devices Agent: Targeting/Weaponeering Experts Agent: Liaisons Agent: Target Planning Tools

– Process Products:

∗ Creates: Target Chart Overlays

∗ Reads: Draft JIPTL

– Constraints JFACC Guidance, Schedules, Assessments, Enemy Assessments, JIPTL

– Description:

Appendix B: ACP Process Products

This appendix describes the process products which are manipulated in the acp domain. Appendix B.1 provides details of the crua matrices which were developed to identify the process products being manipulated in a specific step in the acp domain. Appendix B.2 provides details of the model developed for the process products and identifies the attributes being modelled and the potential values an individual attribute may take.

Appendix B.1: CRUA Matrices

A series of matrices have been developed which show each of the activities in the acp process and the process products it creates, reads, updates or approves and are referred to as a crua matrix.

Appendix B.2: Process Product Features and Values

The following list provides details of the acp process product features and their potential values. In each case the features is named e.g. status and the relationship of its potential value(s) defined e.g. set, scalar, vector or boolean. The features and values are as follows:

• Process Product Type: Scalar: Every process product has this description element. Process Product Type includes, ato, aco, jiptl, etc.

• Contents: Scalar:

Every process product has this feature.

• Contents Type: Scalar:

Every process product has this feature. It could use the mime types as values for the field.

• Description of Contents: Vector: This describes the contents of the process product and would vary for different classes of process products. Examples of the content descriptions are as follows:

– primitve: This is the sequence of characters which comprise the process product.

– compound: This provides a list of the process products which when composed form the process product. A compound process product may be a single item as in the ato or it may be a more loose grouping of objects. For example, the process product referred to as “current status” is composed of a number of briefing which are not collated into a single document.

Summary and Future Work 43

Process Product Analyze Intelligence/Target Information Link Targets to Target Sets Identify Critical Nodes/ Elements Select Targets Assess Target

Vulnerability Select Functional Damage Criteria

Integrated Database

R

Procedure  R(N)  R(N)  R(N)  R(N)

Functional Connection

R(N)

Physical Connection

R(N)

Historical Precedence

R(N)

Logical Connection

R(N)

JFACC Guidance R(N)

R(N)

R(N)

R(N)

R(N)

R(N)

Targeting Objectives R(N)

R(N)

Combat Assessments R(N)

R(N)

R(N)

Assessments  R(N)  R(N)  R(N)

External Environment R(N)

R(N)

R(N)

Target Planning Tools R(S)* R(S)* R(S)* R(S)* R(S)*

R(S)*

Target Database System R(S)* R(S)* R(S)* R(S)* R(S)*

R(S)*

Intelligence Specialists R(S)* R(S)* R(S)* R(S)*

R(S)*

Target/Weaponeering Experts R(S)* R(S)* R(S)* R(S)* R(S)*

R(S)*

Communication Devices R(S)* R(S)* R(S)* R(S)* R(S)*

R(S)*

Planners  R(S)*  R(S)*

Request for Intelligence C C

C

Existing Target Sets R, U

R(N)

Critical Nodes/Elements C

R(N)

JTL  R(N)
ROE  R(N)  R(N)
LOAC  R(N)  R(N)

Previous Plans

R

Fallout Targets

R

Request for Additional Guidance

C

Recommendation for ROE Modification

C

Request for LOAC Interpretation

C

Recommended Changes to JTL

C

Initial JFACC Targets/ CTL C

R

Available Assets

R(N)

JFACC JIPTL Target Candidates C

R

JFACC JIPTL Target Cates with Functional Damage Criteria

C

Table 1: Develop Candidate Target Set

Process Product Evaluate Joint Air Targets Deconflict Joint Air Targets Develop Special Asset Requests Prioritize Joint Air Targets

JFACC JIPTL Target Candidates With Functional Damage Criteria

R

Component Target Information Report

R

Target Information Response

R

JTL  R(N)

Intelligence Information

R(N)

Higher Echelon Guidance R(N)

R(N)

R(N)

R(N)

JFC Directed Targets

R(N)

ROE  R(N)  R(N)  R(N)
LOAC  R(N)  R(N)  R(N)

Combat Assessments R(N)

R(N)

R(N)

R(N)

Procedure  R(N)  R(N)  R(N)

External Environment R(N)

R(N)

R(N)

Schedules  R(N)  R(N)

JFACC Guidance R(N)

R(N)

R(N)

Targeting/Weaponeering Experts R(S)*

R(S)*

Communication Devices R(S)* R(S)* R(S)*

R(S)*

Liaisons  R(S)*  R(S)*  R(S)*  R(S)*
JAG  R(S)*  (S)*

Planning Tools R(S)*

R(S)*

Planners  R(S)*  R(S)*  R(S)*
JFACC  R(S)*

Request for Intelligence

C

Target Information Request

C

Evaluated Joint Air Targets C

R

Component Plans R R

R

Special Asset Response R R

R

Component Target Coordination Feedback C U

U

Deconflicted Joint Air Targets C R

R

Special Asset Request C

R

Draft JIPTL  C

Table 2: Develop Draft Joint Integrated Target List

Process Product  Review  Target

Graphics Determine DMPI Options Determine Weaponeering Options Select DMPI with Valid Weapon System Options

Target System Assessments

R(N)

Draft JIPTL  R(N)  R(N)  R(N)  R(N)
JIPTL  R(N)  R(N)  R(N)  R(N)

JFACC Guidance R(N)

R(N)

R(N)

Schedules  R(N)  R(N)  R(N)  R(N)

External Environment R(N)

R(N)

R(N)

R(N)

Graphics Response

R

Graphics Database

R

Request for Mensurated Coordinates R C

R

Request for Target Element Measurements R C

R

Request for Intelligence C

C

Request for Additional Guidance C C

C

Mensurated Coordinates C R

R

Graphics Tools

R(S)*

Target Planning Tools R(S)* R(S)* R(S)*

R(S)*

Liaisons  R(S)*  R(S)*  R(S)*  R(S)*

Target/Weaponeering Experts R(S)* R(S)* R(S)*

R(S)*

Functional Damage Criteria R(N)

R(N)

R(N)

ROE  R(N)  R(N)  R(N)

Munitions Effects Assessment

R(N)

LOAC  R(N)  R(N)  R(N)

Available Assets

R(N)

DMPI Options C R

R

Target Element Vulnerability Estimates C R

R

Communication Devices R(S)* R(S)*

R(S)*

JMEM Methodologies R(S)* R(S)*

R(S)*

Recommendation for New/Additional Weapon Systems C

C

Weaponeering Options R C

R

DMPI With Recommended Weapons Systems

C

Table 3: Provide Weaponeering Assessment

Process Product Build JTCB Target Briefing Build Target Chart Overlay Special Asset Request

R

DMPI With Recommended Weapons Systems

R

Recommendation for New/Additional Weapon Systems

R

Recommended Changes to JTL

R

Draft JIPTL  R  R
LOAC  R(N)
ROE  R(N)

JFACC Guidance R(N)

R(N)

Schedules  R(N)  R(N)
Assessments  R(N)  R(N)

Enemy Assessments R(N)

R(N)

JIPTL R(N)

JTCB Briefing

C

JAG  R(S)*
JFACC  R(S)*
Planners  R(S)*

Communication Devices R(S)*

R(S)*

Targeting/Weaponeering Experts R(S)*

R(S)*

Liaisons R(S)* R(S)*

Target Planning Tools R(S)*

R(S)*

Target Chart Overlays

C

Table 4: Develop Target Products • Availability: Boolean:

This describes the availability of the process product and simply defines whether the process product exists or not. Examples of this class are as follows:

– not available

– available

• Type-Information: Scalar: The type-information describes the type of information contained within the process product. The types defined for each class of process product must be mime compliant.

• Contents level: Scalar: The contents level defines the different levels at which the contents of a process product can be “measured”. The measurement levels will be different for each class of process product and will be defined as needed. Examples of measurement level include:

– none

– initial

– working version

– draft

– rough

– potential

– CONPLAN

– OPLAN

– Level(n)

In a compound process product i.e. one made up of a number of sub-products there is no contents level. Only “primitive” process products have contents level. In the case of a “level n” tag there needs to be an agreement between the agents involved in the process of what constitutes contents down to a given level. These contents levels can be ordered and the default for most process products would be:

      none --> CONPLAN --> OPLAN

or

      Level(0) --> Level(1) ..... Level(n)

When a agent or activity requires a process product which has contents at a certain level the workflow planner should be able to satisfy this by finding the process product at that level or greater. For example, if an activity requires a process product at the conplan level and one exists at the oplan level then this would be suitable. In order to compare the contents level of different process products there needs to be a partial ordering on the contents level values defined.

• Review-Status: Scalar:

This describes the review status of the process product as it is reviewed and passed through the acp process.

– on-going

– cut-off

– final

• Approval/Recomendation-Status: Scalar: This describes the status of a process product as it transitions from being recommended to approved. (A number of steps on the acp process can start once a recommended jiptl or tnl is available but must not complete until there “results” have been checked against an approved jiptl or tnl.)

– recommended

– approved

• Issue-Status:

This describes the availability of the process product to other agents and systems. Examples of issue status include:

– current

– unreleased

– released

– published

– issued

– proposed

The items described above form the elements of a proposed ontology of primitive process product feature descriptors. These features could be used in higher level reasoning to deduce new information about the process products. Details of some of the derived information is as follows:

• Status: Set:

This describes the status of the process product as it “moves” through the planning process. The status values will be vary for different process products classes and examples of status values include:

– availability (boolean)

– description of contents (scalar)

– review status (scalar)

– issue status (scalar)

For example, the status of the jiptl) could be described as (status: available compound approved released). The status values for different classes of process product would have to be agreed between the agents in the process in order to avoid different values appearing in the slots of the status descriptor. All process products must have a status.

• Access-Information: Set: The access-information describes the types of access made to the process product and the agent and time at which it was carried out. Examples of access-information include:

– modification type e.g. create, modify, user (scalar)

– agent involved (scalar)

– date (scalar)

Appendix C: ACPT Tool Capabilities

This appendix describes the capability descriptions developed to describe the capabilities of the tools within acpt. Previous work [1] developed a simple capabilities model based on the the verb only and this appendix describes how this has been developed further to include the noun and qualifier phrases. Each system and technology has is described in a separate subsection. The systems and technologies described in this report are a representative sub-set of those in acpt, however, the eventual aim of the research is to categorise all systems within acpt.

Expect

The expect tool being developed at usc/isi is a knowledge acquisition framework which can be used acquire knowledge concerning a problem or domain. This knowledge can then be used to review plans and to highlight “issues” which may need to be addressed.

The capabilities of the Expect systems can be described by the class of verbs associated with Review in the verb classification described in Appendix A. The expect tool can be described using the following verb/noun/qualifier descriptions:

Verb  Noun Phrase(s)  Qualifier(s)
Appraise  the situation  produce a report/briefing
Summarise the situation  produce a report/briefing
Critique the situation report issues
Suggest  fixes to issues identified

Sipe

The Sipe tool being developed at sri is a planning system which aids the user in decomposing a specified task into a sequence of activities which can be enacted.

The capabilities of the Sipe system can be described by the class of verbs associated with Develop and Modify in the verb classification described in Appendix A. The sipe system can be described using the following verb/noun/qualifier descriptions:

Verb Noun Phrase(s)  Qualifier(s)
Produce course of action  from a task input
Modify course of action  due to environment and tasking

O-Plan

The O-Plan tool being developed at aiai is a planning system which aids the user in decomposing a specified task into a sequence of activities which can be enacted.

The capabilities of the O-Plan system can be described by the class of verbs associated with Modify in the verb classification described in Appendix A. O-Plan always takes a partial plan and modifies it. The O-Plan system can be described using the following verb/noun/qualifier descriptions:

Verb Noun Phrase(s)  Qualifier(s)
Modify course of action  due to environment and tasking

trains

The trains system being developed at the University of Rochester is a user dialogue tasking and planning system which aids the user in decomposing a specified task into a sequence of activities which can be enacted.

The capabilities of the trains system can be described by the class of verbs associated with Assess, Communcate and Develop. This indicate a mixture of different capabilities which is reflected in it mixed initiative approach to problem solving. The trains system can be described using the following verb/noun/qualifier descriptions:

Verb  Noun Phrase(s)  Qualifier(s)
Describe  situation to system  (from user)
Modify  of changes in the situation  (from system)
Suggest  action, course of action, or constraint (from system or user)
Request  action or course of action  (from system or user)
Acknowledge or Reject  suggestion/request  (from system or user)
Correct, Clarify or Elaborate something  (from system or user)
Summarise or Describe  situation or plan  to user (via system)
Authorise  action by system  (from user)

Appendix D: ACP Activity Grammar

This appendix describes the grammar which has been developed to describe the steps in the acp process. The grammar categorises the noun and qualifier phrases which can be associated with a specified verb. The contents of the noun and qualifier phrases are as follows:

• noun phrase(s) refer to either the process product or the process object meaning manipulated.

• qualifier phrase(s) refer to qualifiers on the way in which the specified verb should be performed^{5}.

In a number of cases it was possible to group together process products and refer to them as a generic group. For example, the candidate target list, service target nominations, jiptl, jiptl cut-off and the target nominations list could be grouped together and referred to a “lists of targets”. Each entry in the table deals with a specific verb and where process products have been grouped together a break down is provided.

5The qualifiers describe adverbs within the acp process

Verb  Noun Phrase(s)  Qualifier Phrase
Deconflict acm Requests
Finalise  Air Control Order

Special Instructions

Air Tasking Order  Quality Control
Produce Air Tasking Order

Target Groupings cas Sortie Allocations Potential Target List Initial Target Nomination List

Weaponeering Assessment  Broad

Weaponeering Force Assessment Mission Support Requirements

Release  Air Tasking Order
Consider Target and Route Threats
Support Developing Objectives
Approve jfacc Guidance
Identify  Support Requests
Review  Current Status
Match Joint Integrated Target List jfacc Guidance
Prioritise Support Requirements

Initial Target Nominations List

Calculate Available Sorties
Develop Time on Target Flows  Rough

Recommended Defence Posture Recommended Apportionment Recommended Target Objectives

References

[1] Drabble, B. and Lydiard, T.J. Model of the ACP Process Verbs and ACP Tool Capabilities, ISAT Technical Report isat-aiai/tr/1, August 1996.

[2] Drabble, B. and Tate, A., Air Campaign Planning Workflow Process Products, ISAT Technical Report isat-aiai/tr/2, October 1996.

[3] Drabble, B., ACP Process Management: O-Plan IFD-5 Qualifier, O-Plan Technical Report arpa-rl/O-Plan/tr/30, October 1996.

[4] Drabble, B., Workflow Models of the Air Campaign Planning Process, ISAT Technical Report isat-aiai/tr/3, September 1996.

[5] Griffiths, A., Kingston, J.K. and Lydiard, T.J., Air Operations Planning Organization, Communication and Task Models,

[6] Hess, D., Theater Battle Management Command, Control, Communications, Computer and Intelligence Architecture (tbm C4I) Air Operations Center (aoc), Report prepared by Government personnel and Mitre Corporation under Contract for Project 6970.