John Kingston and Terri Lydiard, AIAI, University of Edinburgh
Last Revision: 14 March 1996 Caveat Emptor comments added: 9 October 1996 Session Type: Model Review Interviewee: Major Mike Cardenas, Checkmate Major Mark Alred, Checkmate Major Jack Allison, Checkmate Interviewer: Anna Griffith, ISX Date: March 21, 1996 Validated: Purpose: The purpose of this session was to review the IDEF3 and CommonKADS ACP models produced by AIAI. The version Dated March 8, 1996 was reviewed. Interview Synopsis: General Comments: 1.Through out the document, the term Air Campaign Plan is used incorrectly. Really what this document is referring to is the Air Operations Plan. 2.Strategy is the key of planning, not objectives. The document is too focused on ACPT instead of strategy and actual air operations planning. 3.Checkmate does not play an official role in the JTF. Any references to this are incorrect. 4.Comments and criticisms made to the models in November were not integrated into the document. 5.The models should first be built based on doctrine and then supplemented with anecdotal information. The current models are built entirely on Anecdotal information. All doctrine and historical references should be referenced. Initial documents to reference are the purple book and joint publications 3-56.1 and 3-0. 6.All time frames specified in the document are inaccurate. Specific Comments on Pages 1- 21 Checkmate gave me comments on only the first 21 pages. Because the basic concepts of the document are incorrect, they did not think it was worth critiquing the entire document since their criticisms were becoming repetitive. Page 7, Section 1, first two paragraphs of the Introduction These two paragraphs are trying to say too much too quickly. Plus, what is being stated is inaccurate. Page 7, Section 1.1 3-56.1 needs to be referenced for accurate information. A JFACC is not required. Page 7&8, Section 1.2 In the first paragraph, several steps are missing between the crisis and establishing a JTF. In the third paragraph, negotiating does not occur. It is more of a feedback loop. The terms engagement plan and mission plan do not exist. On page 8, ROEs are negotiable and are changed throughout the execution of the plan. The critiques of INTEL should not be included. In general, the coverage of INTEL is nonexistent. Future models should cover that aspect of planning. Page 8&9, Section 1.3 This section is completely wrong. The three stages of planning are not what is listed. The heart of planning is transforming the CINC guidance and intent into strategy. Objectives are a tool to distill strategy into something executable. The last paragraph on page 8 is wrong. The last paragraph of section 1.3 on page 9 is wrong. The JFACC will lead the process. Page 12 Figure 2 is wrong. The process needs to be from doctrine. Some of the steps mentioned in figure 2 do not have to be done during the planning process. There is no such thing as "schedule target list". A JTF MAY be formed. The ACPT and CTEM twist of the model should be removed. Page 14 An Ops group does not exist. The DMPI details are inaccurate. The "weaponeer target list" information can be found in 3-56.1. A JEMS person needs to be consulted on the weaponeering topic. "produce mission plan" should be eliminated. The AOC will never communicate directly with the flight leader. "evaluate air campaign" is wrong. We need to talk with an INTEL person. Page 15, Section 3.3 The first two paragraphs are wrong. This type of information should be found in a doctrine document and then referenced. The wings description is inaccurate. It is also probably inappropriate for the model. Page 16 The JTF is different every time. The organization of peacetime and war is different. We need to reference doctrine. Page 17 There are too many concepts in one chart. It seems like there is some structure and some process; and it is inaccurate. Page 18, Section 3.6 Security is an issue when conducting planning. But, rights is a concept not used in the military. The military should not be so openly criticized. If you would like to include a historical anecdote to make a point, it should be referenced from a published document or book. Page 19 Look in the purple book for this information. CNN is not formal input. We should call this open source or non-INTEL. The MAAP is in the wrong place. The diagram is essentially inaccurate. Page 20, Section 4 The process described in the second paragraph only occurred in Desert Storm. Page 21 This diagram is wrong. The hierarchy presented in inaccurate. They didn't understand the point of the diagram. "responsible" and "obliged" are not terms they use.
These diagrams are based on knowledge acquired from two staff members from ISX who were formerly part of the USAF, four members of Checkmate, [1] and documents provided by these domain experts.
[1]
Checkmate is a group of expert air planners at the Air Force
Headquarters in the Pentagon, who may play a role in a
JTF by augmenting the JFACC planning group or by working separately from
the JFACC planning group. Checkmate was originally a war gaming center for
evaluation of plans with a focus on high level strategy; for example,
Checkmate modeled WWIII in Europe so that logistics, purchasing and training
could be planned in the event that a crisis occurred. However, the senior Air
Force officers often use Checkmate to supplement their planning staff. As
a result, Checkmate personnel have real world planning experience even though
it is not in the group's original charter.
A full description of the Air Campaign Planning process requires analysis on two levels:
This document concentrates on a description of the the process of creating an air campaign plan, using a multi-perspective approach based on the CommonKADS methodology Breuker94. However, the Expertise Model, which is a key component of the CommonKADS methodology, is designed to represent both a (specific) process and the domain knowledge which it manipulates; in other words, to model both activities and objectives. An analysis of objectives was performed in order to support this model; some results can be seen in Appendix Centers of Gravity.
Caveat Emptor:
The document was created as an intermediate step towards a final document.
Checkmate have criticised a number of points in this document, and an
The knowledge acquisition effort which is described in this document focused
on air campaign planning within a Joint Task Force (JTF). A JTF exists for one
crisis (which usually implies one theater); however, there may be more than
one JTF per theater. The JTF is under the control of the Joint Forces
Commander (JFC).
The Joint Forces Air Component Commander (JFACC) is the functional
commander responsible for the air operations within the overall
campaign. The JFACC is appointed by the JFC, who usually selects the
component commander contributing the greatest number of air assets to
the JTF. The work of the JFACC and his staff is carried out in the
Joint Air Operations Center (AOC).The JFACC reports to the JFC, who reports
to the Commander in Chief (CinC) of the theater.
A Campaign Plan is a plan for all forces participating in a JTF and
typically covers a 6 month period. Each functional component within
the JTF will also have a specific campaign plan. The Air Campaign
Plan also covers a 6 month period. The overall plan is represented and
transformed into a Master Air Attack Plan (MAAP), from which the Air
Tasking Order (ATO), or battle plan, is produced. The ATO takes 36 hours to
produce and covers 24 hours. Mission Plans are derived
from the ATO; a mission plan constitutes the directions for a specific sortie.
Pilots then develop an Engagement Plan, which specifies the
maneuvers that will be used to execute the mission plan.
Once a crisis occurs, the CinC assesses the situation, selects a Course of
Action and may decide to establish a JTF. Then a warning order is
given, normally 3 days in advance of the commencement of operations.
Operations are initiated by a further order from the CinC, known as the
Operations Order.
When a crisis occurs and the CinC decides to take some action, the CinC
will provide planning guidance to the JFC. The guidance is
communicated to the component commanders (e.g. the JFACC) through the JFC.
The component commanders will in turn communicate the guidance to their
planners. Based on the guidance, the planning staff will take between 3 days
and 1 week to build a plan that may be executed.
Although the guidance (at every level) is considered to be an order rather
than a suggestion, negotiation does take place. If a commanding officer
proposes certain objectives or goals that are unreasonable, then participants
in the planning process have the responsibility for convincing the commanding
officer to take a different approach. For example, the planners may want more
time. But, to buy time in a crisis, something diplomatic has to be given
up. The commanding officer may not be willing to make a diplomatic sacrifice.
In some such situations, the commanding officer will enforce the initial
guidance; in other cases, the initial guidance may be relaxed.
However the Rules of Engagement (which are part of the initial guidance from
the CinC) are never negotiable.
Initial planning steps include assessing the situation and organizing the
planning staff. Assessing the situation involves identifying enemy centers
of gravity (COGs) [2]
and air defenses as well as determining a strategy and defining high level
objectives. A lot of knowledge about the theater is needed; typically the
planning staff has been studying the theater for years. The types of
information they know are whether the enemy has nuclear weapons, the nature
of the crisis, and the history of the conflict. The planning staff have, and
use, many maps with different perspectives of the theater.
When the planners cannot find required details,
they will rely on contacts with people who have the information or can get
the information. Typically these are intelligence people on the planning team.
It's often impossible to prove the accuracy of intelligence data,
because INTEL (the intelligence group) must protect their sources; however,
duplication of INTEL effort between different branches, which is encouraged,
may corroborate information or provide additional information.
If the planners cannot obtain the required information in time (it can take 3
days for information to arrive),
they will make assumptions and move to the next step.
Throughout the planning process, air planners are searching for alternatives,
vulnerabilities, consequences and contingencies.
The heart of the planning process consists of three stages:
The planning team usually consists of 8 people working 8-hour shifts (12 hours
in a crisis), which is only sufficient
to plan for one situation (the most likely case) and look very
hard at one other alternative (probably the worst case).
The planning staff hold 4-hourly meetings to discuss progress, obtain a
consensus of opinion, and to make sure that there is a smooth
transition between phases. The latter is very important, since it is
imperative that friendly forces are not
perceived by the enemy as being indecisive.
It's important to note that the planning process does not always continue
until each stage is fully completed. Often, the planning staff may only be
75\% finished with some activities when it is time to move on to the next
stage. This is usually due to resource constraints (insufficient staff to
perform more detailed analysis), although there is also a temporal constraint;
the dynamic environment in which planning takes place means that the situation
may have changed by the time thorough planning is completed.
In most cases, the JFACC will not want to be involved in the planning
process except for a daily briefing to make sure that guidance has
been communicated correctly.
This lack of involvement from the JFACC is deliberate and is designed
to foster openness and innovation. The air planning team does not normally
communicate with other branches
either, in order to enhance creativity, and to reduce the constraints of
reconciling too many points of view.
The modelling technique used to model the ACP process was based on the
CommonKADS methodology for knowledge modelling.
CommonKADS Wielinga92c Breuker94 is a collection of structured
methods for building knowledge based systems, analogous to methods such as
SSADM for software engineering. It was developed between 1983 and
1994 with funds from the European Community's ESPRIT program.
CommonKADS views the development of a knowledge based system as a
modelling activity, and so the heart of the method is the construction of
a number of models which represent different views on problem solving
behavior. Knowledge engineers are encouraged to construct some or all of the
following models:
Each of these models consists of one or more diagrams, showing different
perspectives on the knowledge contained within that model. For example,
one perspective
might model the activities which take place in an organization, while a
different perspective may represent the structure of that organization.
Each perspective therefore represents all acquired knowledge of a particular
type. The strength of this ``individual perspective'' approach appears when
the knowledge engineer tries to make the knowledge contained in the different
perspectives consistent; the presence of certain knowledge or data in one
perspective frequently highlights missing knowledge in another perspective.
This document provides CommonKADS models for the Air Campaign Planning process
and its surrounding environment. The models which are included are:
The stated aim of modelling the Air Campaign Planning (ACP) process was to
perform a ``task
analysis'' of the ACP process. However, after initial knowledge acquisition,
it was felt that there was considerable benefit to be gained from producing an
Organizational Model, showing the organization which surrounds ACP, before
analyzing the activities performed during the ACP process in detail. The
organizational model contains information on the activities, [4] the {\em
agents} and the resources which are used in the air campaign planning
process, as specified in Figure richmodel; each perspective is
represented by a single diagram, or by text.[5]
The organizational model also
contains ``cross products'' of these three different perspectives (again, see
Figure richmodel), which sometimes provide
the most useful information. For example, the CommonKADS Organizational Model
was used to model a Social Security department; a cross-product of activities
and structure was produced which highlighted an area of inefficiency, because
one of the activities (archiving) was being performed by three different
divisions of the department deHoog93.
The Dictionary perspectives are simply sets of activities (or agents or
resources) which are used as a basis for building the other perspectives. The
Network perspectives show how entities of the same type relate to one
another:
The Cross Product perspectives show how resources are produced, used,
consumed or modified within the process (Assets perspective), what
rights
agents have to resources (Rights perspective), and the obligations and
responsibilities to perform activities and to create states of affairs (
Responsibilities perspective).
Figure proctop shows the activities which represent the overall workflow
of Air Campaign Planning, and also shows how these activities link to form
processes.
Key: Introduction to Air Campaign Planning
Plan Components
Preparation for planning
[2]
COGs are described in more detail in section Centers of Gravity.
Planning
The planning may be subdivided according to different phases of the conflict,
or possibly on other dimensions (e.g. geographical area).
[3]
The terms ``task objective'' or ``Course of Action'' may be used by some to
refer to air tasks
Introduction to the modelling technique used
Organizational Model of the ACP process
Introduction
[4]
CommonKADS actually calls these ``functions'' rather than ``activities''; at
lower levels of detail, the term ``tasks'' is used instead.
However, for reasons which are explained in Uschold95, I have chosen to
use
the term ``activities'' throughout this document.
[5]
This organizational model is a variation of the model proposed by CommonKADS.
The reasons for this variation are discussed in appendix
CommonKADSAppendix
Process Perspective
Solid link | the first activity precedes the second |
---|---|
Dashed link | there is an information flow from the first activity to the second. |
Description of activities:
All of these types of guidance will change dynamically throughout the planning process as well as the execution of the plan.
In the course of scheduling the air campaign plan, the Ops group sometimes find and report anomalies in the plan.
Weaponeering is currently one of the most time-consuming parts of the whole planning process, taking around 10 hours to complete. The weaponeers use a system known as Rapid Air Action Planner (RAAP) which suggests 5 possible options for resourcing a mission. RAAP can be time-constrained (i.e. forced to plan all missions within a particular time), but it cannot be resource-constrained (forced to plan missions using only certain aircraft). This means that the options suggested by RAAP may conflict with resource allocations explicitly required by senior officers, or resource allocations suggested by the CTEMS system. It has been suggested that the weaponeers could make use of the output of CTEMS as a starting point for weaponeering, but this is currently a subject of internal debate.
The effect of feedback is to adjust the prioritization of task objectives and of targets. If new policy and guidance is received, the prioritization of air objectives may also change.
Figures strucfor and strucjf show two different aspects of the
organizational structure surrounding the ACP process. Figure strucfor
shows the structure of the US armed forces (AFFOR, ARFOR, NAVFOR, MARFOR and
SOF) which may be present within a Joint Task Force. Figure strucjf
shows the structure of the Joint Forces
Command, including the staff who produce the Air Campaign Plan and report to
the JFACC, and the upper echelons from whom the JFACC receives
instructions.
When viewing these diagrams, it should be borne in mind that different
senior officers will choose to work in different ways; to be more precise, the
CinC may alter the lines of authority or reporting requirements, in order to
improve his liaison with selected groups or individuals. This means that
these diagrams, particularly the upper levels of a Joint
Forces Command, may be adjusted according to the CinC's own preferences.
Structure Perspective
Key:
Dashed link | this department or unit is a department of another department or unit. |
---|
Partial description:
N.B. Once a mission is in progress, the term flight is used to apply to a subgroup of aircraft within the mission forces. A ``mission flight'' typically consists of 4 planes, which may be drawn from one or more ``squadron flights''. The Navy avoid this confusion by using the term section for a ``mission flight''.
Key:
Solid link | the first agent reports to the second |
---|---|
Dashed link | the agent belongs to the department |
A State of Affairs indicates that one or more resources have reached a certain
status which is important to the ACP process. Since most of the resources used
by ACP planning are passive resources (e.g. documents), most of the important
states of affairs will correspond to the completion of certain documents.
No states of affairs have yet been fully documented; however, the diagram
of the Responsibilities perspective responsibilities below illustrates
some possible states of affairs which might emerge as being important.
The Assets perspective (see Figure assttop) takes the activities
identified in the Process perspective, but instead of showing precedence
relationships, it provides information regarding the resources which are
produced, consumed, used or modified by the various
activities. Three different types of resources are distinguished: passive
resources (documents or files); computer resources
(computer programs e.g. databases); and human
resources (normally implying a source of knowledge).
Figure 11: ACP Assets Perspective: Top Level
The rights perspective represents
the authority of various individuals or groups to view or to alter certain
resources. By representing this authority, it becomes possible to frame
discussions about the consequences of changing these rights.
An example of the consequences of changing rights can be drawn from Desert
Storm Thaler95. General Schwarzkopf, the CinC, not only briefed all
Joint Force Commanders at meetings, he also sometimes gave out guidance or
instructions to an individual Joint Force Commander by telephone or in private
meetings. One such instruction, given to the JFACC, was that Iraqi units
believed to be below 50\% of full combat strength should no longer be targeted
for air strikes. This instruction was not communicated to the land commanders,
who were left to wonder why the Air Force had ceased to provide them with
close air support; indeed,
many did not find out about this instruction until after the war! It can be
seen that the CinC decided to withdraw (or neglected to provide) the JFLCC's
rights to view the instructions and guidance which the CinC was providing to
the JFACC, and that the result was uncertainty and possible irritation within
the ground forces. Of course, there may be advantages (e.g. in security) in
General Schwarzkopf's approach; but it is important to have a framework for
weighing the pros and cons of a particular decision, and it is hoped that the
rights perspective could provide such a framework.
Very little knowledge has been acquired on ``rights'' within the process of
planning an air campaign. This perspective may prove much more useful if the
modelling is extended to look at the precursors of air campaign planning, such
as the formation of a JTF, or selection of a course of action.
Key: States of Affairs
Assets Perspective
Solid link | the agent has a right to the resource |
---|
Responsibilities Perspective
responsibilities
The Responsibilities perspective shows which agents are responsible to which other agents for a state of affairs, and what obligations agents have as a result of their responsibilities. As with the Rights perspective, there has been little information gathered for the Responsibilities perspective at present; the diagram in Figure responsb illustrates the format which a diagram of the Responsibilities perspective would take.
Key:
Link with black circle | the first agent is responsible to the second for a state of affairs (which is indicated by the label on the link) |
---|---|
Link with white circle | the agent is obliged to perform the activity |
The CommonKADS Task Model is a more detailed version of
the process perspective of the organizational model. The process perspective
of the organizational model is intended to represent the overall workflow
and/or control flow of an organization's primary processes; the task model
describes the activities which are executed in an organizational environment,
with an emphasis on deciding
which activities could be suitable candidates for computer software support
Breuker94. The extra detail includes the inputs and outputs of
these activities; the agents who can perform these activities; and any
temporal restrictions on activities.[6] The results of the analysis are displayed in a diagram,
showing dependencies between different activities, and (optionally) the roles
of the agents who are expected to take on these activities.
Once the organizational model had been produced, a task model was produced
which focused on the strategic planning of an Air Campaign Plan. The part of
the process which was considered started with the CinC issuing policy and
guidance to the JFACC for use within the planning process, and finished with
the production of a Master Air Attack Plan (MAAP). This closely corresponds
with those parts of the Air Campaign Planning process which are carried out by
the planning staff at the JFACC's Air Operations Center.
One of the main purposes of the task model is to help in deciding
which activities could be suitable candidates for computer software support.
In order to support this decision, some further information about the
activities was acquired, using the ``repertory grid'' knowledge acquisition
technique (see appendix appxrepgrid). The information acquired was:
Task models were developed for two of the activities identified at the top
level of air campaign planning. These activities were Prepare for Air
Campaign Planning and Plan Air Campaign.
In order to improve the quality of information which can be conveyed by the
diagrams, the IDEF3 technique was used instead of CommonKADS' suggested
diagram format. This technique represents
the exact ordering of processes in more detail than the graphical format
suggested by CommonKADS.
The task model for preparing for air campaign planning is shown in the Figure
below.
Description of activities:
The content of the guidance is likely to be at the level of theater
political objectives and theater military objectives. These may include:
The policy and guidance should also include Rules of Engagement which have
been defined.
Attributes:
In the later phases of an operation, the planning staff's interpretation of
policy and guidance is endorsed by default -- that is, if they don't hear
anything, they assume that there are no problems. The guidance should be
reviewed by the planning
staff at least once per day, to take account of possible changes. Changes may
occur if the President makes new public statements; or if allies join
or leave the coalition; or if the enemy sues for peace.
Attributes:
In a long conflict, there's effectively an annual review because of annual
cycling of personnel (which normally implies a new Chief of Plans).
Attributes:
It's a very important process; if you can predict the enemy's plans, you have
a huge advantage.
Attributes:
This process is particularly common in the case where the JFACC does not
explicitly specify objectives; but if he does, the planning staff still need
to clarify and review the objectives for completeness. This ``sceptical
review'' is an accepted part of the planning staff's function; indeed, it
seems to lie at the heart of several of the processes carried out during air
campaign planning.
This activity requires looking at the
situation assessment produced when determining a course of action, and trying
to identify and correct any weaknesses with this assessment. The factors
considered will include:
The situation assessment provides planning and evaluation
context, which is referenced all the time as things change in the real world.
This context is used as a frame of reference for communications. Note that
the primary use of this frame of reference is to foster communication between
the JFACC and the staff who are directly responsible to him; the frame of
reference is probably only fully understood by the JFACC, the planners,
and the other personnel in the Air Operations Center. It
may filter further upwards through the planning hierarchy until it
supports the President's picture of events, but it isn't
understood by individual pilots.
There is not much lateral communication (between different components of the
JTF), which is unfortunate, as failure to agree a common situation assessment
between different components can cause problems. The AOC planning
meetings will be attended by the Liaison Elements from the other components,
but they don't formally report back to their own component commanders. In
addition, there is no guarantee that the JFC will agree with a component
commander's assessment of the situation; taking Desert Storm as an example,
the JFC considered the Republican Guard to be an important center of gravity
for the Red forces, whereas the JFLCC did not consider them to be
particularly important.
Attributes:
This involves a group of planners meeting together and trying to identify as
many enemy centers of gravity as possible. Centers of gravity can be specified
at different levels of abstraction; a suggested hierarchy of centers of
gravity can be found in appendix Centers of Gravity. The brainstorming activity
generates centers of gravity which are suitable for inserting into air
objectives. At this level, centers of gravity may take one of a number of
forms:
Centers of gravity are considered under the following five headings:
Attributes:
The task model for planning an air campaign is shown in Figure procacp.
Description of activities:
Attributes:
The planning team will also establish metrics for evaluation of the
effectiveness of a
phase; the metrics may include cost, logistics, intelligence reports (from the
JFACC's intelligence staff, commonly known as INTEL), and resources.
Attributes:
Attributes:
Attributes:
Attributes:
At this point, the list of targets is sent to the Joint Targetting
Board, who will discuss it and alter it to produce a revised Target List. This
modified target list is then incorporated into
the Master Air Attack Plan (MAAP), which is passed to the Ops group for
weaponeering and scheduling. Scheduling is performed using the CTEMS system,
which identifies if there are suitable resources available to strike
the suggested targets; weaponeering is performed using the RAAP system. These
activities result in the Air Tasking Order (ATO), which specifies missions to
be flown.
Sometimes, the the JFACC or another senior officer will provide specific
guidance to the schedulers and the weaponeers; for example, if there is a
shortage of munitions, he will direct that certain munitions are reserved for
certain targets. The planners will usually take this guidance into account
during planning.
There may be occasions where a
target which is identified as worthy of attacking by air could be targeted by
Army helicopters or ground-based SOF forces with equal or greater efficiency.
In such cases, there will first be informal liaison between the AOC planners
and the appropriate land forces to determine if it's feasible for the land
forces to take on the operation; if so, the JFACC will include a request for
these forces in his briefing for the JFC.
Interaction with land forces gives the relevant land forces rights to view the
Master Air Attack plan, for the sake of deconfliction of operations.
The assets perspective for preparing for air campaign planning is shown in
Figure asstprep. It shows the activities identified in the Task Model,
along with the resources which are produced, used, modified and consumed by
these activities.
Key: Task model
[6]
The full list of activity attributes can be seen in the descriptions of
activities given in the models themselves. The list is not entirely derived
from CommonKADS; instead, it is derived from the AIAI Enterprise Ontology
Uschold95.
Task Model: Prepare for Air Campaign Planning
Key:
Task Model: Plan Air Campaign
It would be helpful to use a further subdivision, in which the best case
scenario, worst case scenario, and most likely scenario were examined
independently. However, this would require breaking down the planning team
into smaller groups, which is usually infeasible due to lack of personnel.
[7]
This is based on the repertory grids acquired from Checkmate. However,
this figure contradicts the opinions of the experts from ISX. This needs to be
verified.
Task Model: Prepare for Air Campaign Planning: Assets Perspective
Labelled link | the activity produces/consumes/uses/modifies the resource |
---|---|
Diamond | Passive resource |
Rectangle | Human Resource |
Rounded rectangle | Activity |
Partial description:
The assets perspective for preparing for air campaign planning is shown in
Figure asstprep. It shows the activities identified in the Task Model,
along with the resources which are produced, used, modified and consumed by
these activities.
Key: Task Model: Plan Air Campaign: Assets Perspective
Labelled link | the activity produces/consumes/uses/modifies the resource |
---|---|
Diamond | Passive resource |
Ellipse | Computer Resource |
Rounded rectangle | Activity |
The prioritization of air objectives usually correlates closely with the sequencing (temporal ordering) or air objectives.
The communication model represents all communication between different agents,
as well as the content of the communication. This information can conveniently
be represented in a single role-activity diagram, which shows which
activities are carried out by which agents, and identifies points at which
communication takes place Ould93.
The communication model is shown in Figure commmodel. N.B. For
implementation purposes, a more detailed
model of communication will be required, showing which agent takes the
initiative, the exact format of transactions, and any other key information
(such as time-critical transactions).
The purpose behind role-activity modelling is to look beyond the
activities which make up a process to the roles of the actors reponsible for
carrying out those activities. This form of modelling has two effects.
The first effect is in providing support to the individual role actors by
being clear about their roles, and in identifying with whom they are
required to interact at each stage of the process in order to
complete their role. The second effect is in identifying
inefficiencies in the process itself.
One indication of inefficiency
within a process is the presence of a large number of interactions
between particular roles. In general, interactions involve the transfer of
information between roles. Verbal transfer
involves personal contact between the role actors, which requires finding
convenient times for meetings, telephone conversations etc.
Transferring information via textual means requires an efficient
transfer mechanism and the motivation of the receiving role actor to act on
that information within a reasonable time. Delays within a process
are particularly prevalent where more than two roles are involved, or
where the role actors are separated geographically.
The following diagram presents a high-level model of some of the
roles and activities occurring within the ACP process. The model shows a
certain amount of interaction between the
JFACC and the planners, and between the JFACC and the Ops role. However it is
thought that this is
unlikely to cause a problem within the the ACP process as the role
actors are all contained within the Air Operations Center; indeed they
are usually situated within the same room. It is possible that some of
the roles indirectly influencing the production of the ACP but outside
the scope of this model, such as interaction between the JFC and all his
Component Commanders, and interactions between the Component Commanders
themselves, may be more likely to be the cause of inefficiencies and
bottlenecks. However this type of role interaction will be dependent
on the battle situation and the personalities of the Commanders involved.
Communication Model
commmodel
The notation used in order to produce the communication model is given in the
accompanying table.[8]
STRIM consists of 2 phases:
The diagrams have been produced using the RADitor software system.
[8]
This notation is based on that described in STRIM, a method for
business process re-engineering developed by Praxis Systems plc.
Role Activity Diagram Notation | |
---|---|
Attribute | Icon and Definition |
process | a set of roles, the overall activity that is taking place |
role | shown as a block. Primary structuring concept. A role is a a sequence of activities performed by a single person or a department |
activity | The details of how the activity is carried out are
unimportant. The activity is performed by the role actor which may be a person
o computer or combination of the two. The role may exist whilst the actor
changes, and one actor may perform more than one role. A number of types of
activity exist: actions, shown as a square. These are performed by a role in isolation interactions, shown as an action in one role box connected by horizontal lines to an action in one or more other role boxes. Interactions indicate that more than one role is involved in carrying out an action. Information may be passed passed between roles during an interaction. start role, shown as a pentagon, causes another role to be created external events, generally ignored but if needed shown as an action with a line arrow going into the left hand side |
state | shown as a circle and used to indicate the start or end of a branch in the actions carried out within a single role, or used as a go-to referring back to an earlier activity within the role |
refinements | indicate that some activities are alternatives
or can be carried out concurrently. Refinements start and finish with a state and are of two types: part refinement shown as two triangles, apex upwards, indicating concurrency; case refinement shown as two circles and indicating alternatives |
\psboxto(15cm;5cm){/home/oplan/html/work/ISAT/jkk/webpage/legend.ps}$$
The purpose of the Task Model is to identify activities which would benefit
from support, particularly computerized support.
It is common for some activities within a task model to be identified as
knowledge-based activities; that is, activities which require
significant expertise, experience or knowledge to enable them to be carried
out well. The most appropriate technique for representing these
activities in CommonKADS is to use the inference structures and {\em
task structures} that form part of the CommonKADS Expertise Model.
There are at least three activities within the Task Model described above
which can usefully be modelled using the CommonKADS Expertise Model; they are
the identification and
prioritization of air objectives, the identification, prioritizing \&
sequencing of air tasks, and the identification and prioritizing of
targets. This document contains a full expertise model for the identification
and prioritization of air objectives, and task structures (partial expertise
models) for the other two
activities. It can be seen that the task structures for all three activities
are similar, which suggests that the full expertise models for these three
activities will have many similarities.
The Expertise Model is a model of the expertise required to perform a
particular activity. It is the most detailed of all the CommonKADS models (see
Appendix CommonKADSAppendix for more information). This model is divided
into three components, each of which is represented by one or more diagrams:
The task structures can be considered as a lower level decomposition of
certain activities in the Task Model. There is no need for an accompanying
Asset perspective, however, because the inference structures supply
information about interactions between activities and domain knowledge.
Expertise Model
Solid link | the first activity precedes the second |
---|---|
Dashed link | there is an information flow from the first activity to the second. |
Description of activities:
This activity takes half a day, which is a long time for a single activity. Despite this, the planners are aware that they don't identify all the centers of gravity, because of lack of time.
Attributes:
Planners usually take a breadth-first approach to the identification of objectives.
Attributes:
Attributes:
Attributes:
The inference knowledge for the identification and prioritization of air
objectives is represented in Figures infairtp through
to infaircl.
It consists of a number of inference steps (ellipses) and knowledge
roles (rectangles). The inference steps, which are labelled according to the
type of inference which is being performed, correspond to activities in the
task structure; the knowledge roles correspond to one or more items of domain
knowledge. Static knowledge roles (which are distinguished by having a
thicker border) indicate knowledge which is not transformed in any way
by the problem-solving process. A ``double ellipse'' for an
inference step indicates that that step is a composite inference step, which
is broken down to a lower level of detail in a subsequent diagram.
Inference Knowledge
Inference steps:
Knowledge roles:
Little information has been gathered so far on this process; the inference steps given below are extrapolated from what has been gathered, and from previous experience with activities requiring selection.
Very little information has been gathered on this process so far, so the descriptions given below are largely hypothetical.
Domain knowledge for this activity has been acquired by analyzing a list of CinC objectives, air objectives and air tasks which was provided by Checkmate. This list can be found in appendix appxobjectives.
The domain knowledge for identifying and prioritizing air objectives consists of three major concepts:
A grammar for expressing objectives is currently being prepared as part of the IFD-4 work; it is hoped that this grammar will specify more precisely the possible combinations of these concepts within each type of objective.
\paragraph{Centers of gravity:}
The centers of gravity which were acquired have been structured into a hierarchy. At the top level, the hierarchy is divided according to Col. Warden's 5-way classification of possible centers of gravity:
The hierarchy is sufficiently detailed that it needs to be spread over several diagrams (Figures cglead to cgforce5 in appendix Centers of Gravity). An example is shown in Figure cgex.
The hierarchies should be read from left to right; the top level centers of gravity are on the left, and the lowest level CoGs are on the right. The links between levels are subclass links; that is, a center of gravity at any level (except the top level) should be considered to be a subclass of the center of gravity at the next level up. The blank boxes are place-holders in parts of the hierarchy which ought to be expanded in order to produced a fully detailed hierarchy of CoGs.
The key observations which lead to this hierarchical structuring were:
From analysis of the objectives, it becomes clear that different levels of abstraction (usually) map to different types of objective. CoGs at the third level of the hierarchy are typically specified within a CinC objective (e.g. ``Disrupt flow of military equipment on national roadways''); CoGs at the fourth level of the hierarchy are typically specified within air objectives (e.g. ``Deny use of key choke points on the roads''); and CoGs at the fifth level of the hierarchy are typically specified within air tasks (e.g. ``Destroy bridges on roads between the capital and the southern border''). Targets should be considered as the sixth level of the hierarchy, although it is not feasible to display them in this document. The 5 levels of the hierarchy therefore correspond to:
A key component of the hierarchies which contributes to the goal of identifying all relevant centers of gravity is the identification of intra-hierarchy links. These show where a center of gravity in a different hierarchy is relevant to a center of gravity in this hierarchy. The name of the related hierarchy is displayed in the bottom half of the CoG node. For example, Figure cginf2, which is shown on page \pageref{cginf2}, includes ``Couriers'' as a center of gravity. Since communication by courier is dependent on a good transportation network, an intra-hierarchy link to ``Transportation'' (which appears in Figure cginf1) is shown as the decomposition of the ``Couriers'' center of gravity.
\paragraph{Actions:}
The types of actions which appear in objectives include words such as {\em disrupt}, destroy, deny use, and attrit. The full list of actions is currently under discussion, including discussions on whether some actions are only appropriate for certain types of CoG. A typical set of actions is given below:
Action | Definition |
---|---|
Disrupt | Temporarily reduce effectiveness |
Degrade | Permanently reduce effectiveness |
Isolate | Reduce effectiveness to zero until further notice |
Destroy | Permanently reduce effectiveness to zero |
The general format of objectives is ``Perform action on center of gravity with modifier''. The modifiers are optional, but many CinC objectives and air objectives, and some air tasks, have associated modifiers. These modifiers may be:
The form and content of permitted modifiers is currently under discussion. A list of (almost) all the identified modifiers was prepared; it can be seen in tables CinCmodifiers and AirModifiers on page \pageref{CinCmodifiers}. A selection of modifiers are shown in table modifierex.
\begin{table}
Center of Gravity | Modifier |
---|---|
Geographical | |
US citizens | in the region |
YOC forces | north of Desired Area |
Temporal |
until the flow of military resources is sufficiently slow |
Categorical | |
YOC political control | YOC armed forces | YOC armed forces |
YOC political control | YOC population |
YOC military control | YOC population |
electricity | YOC population |
petroleum products | YOC population |
national television systems | YOC population |
national radio systems | YOC population | YOC population | \caption{Modifiers: CinC Objectives Level} modifierex
The task structure
for producing and sequencing air tasks can be seen in Figure
TaskStrucTaskObj.
One of the main
discoveries from this modelling exercise has been that the processes involved
in producing prioritized air objectives, producing prioritized air tasks
and producing a prioritized target list are very similar (see Figures
TaskStrucAirObj, TaskStrucTaskObj and TaskStrucTargets).
This observation, coupled with the hierarchies of centers of gravity (which
suggests a similar format for domain knowledge in each of these three
activities), suggest that the entire expertise models for these three
activities will be very similar. It would, however, be instructive to identify
any differences between these three models.
Key: Prioritizing Air Tasks
Task Knowledge
the first activity precedes the second | |
Dashed link | there is an information flow from the first activity to the second. |
Description of activities:
For example, if ``disrupt command and control'' had been specified as an Air Objective, possible air tasks might include:
At present, the only information available which resembles inference knowledge
for the activity of producing and sequencing air tasks is the ``assets
perspective'' diagram shown in Figure InfStrucTaskObj. However, as
discussed above, the inference structure is likely to be similar to the
inference structure for identifying \& prioritizing air objectives, shown in
Figures infairtp through infaircl.
Key: Inference knowledge
the activity produces/consumes/uses/modifies the resourc |
Passive resourc |
Computer Resourc |
Activit |
As discussed above, the domain knowledge for air tasks consists of
actions, modifiers, and centers of gravity taken from the hierarchy shown in
appendix Centers of Gravity; for information
on these, read section DomainAirObj
on page \pageref{DomainAirObj} on domain knowledge for air objectives. The
hierarchy shows that a certain level of CoGs are specific to air tasks. It is
possible that certain actions or modifiers are specific to air tasks; this is
still under discussion.Domain Knowledge
the first activity precedes the second | there is an information flow from the first activity to the second. |
At present, the only information available which resembles inference knowledge
for the activity of producing a prioritized target list is the ``assets
perspective'' diagram shown in Figure InfStrucTargets. However, as
discussed above, the inference structure is likely to be similar to the
inference structure for identifying \& prioritizing air objectives, shown in
Figures infairtp through infaircl.
\begin{center}
Figure 15: ACP Assets Perspective: Prioritize Targets
\end{center}
Key: Inference knowledge
the activity produces/consumes/uses/modifies the resourc |
Passive resourc |
Computer Resourc |
Activit |
N.B. The asset database is not connected to any activity because it is not currently used by the planners.
As discussed above, the domain knowledge for air tasks and targets consists of
actions, modifiers, and centers of gravity which implicitly form the sixth
level of the hierarchy shown in
appendix Centers of Gravity; for information
on these, read section DomainAirObj
on page \pageref{DomainAirObj} on domain knowledge for air objectives. It is
possible that certain actions or modifiers are specific to targets; this is
still under discussion.
\newpage
\bibliographystyle{/home/mfu/LaTeX/newannotatedharvardbib}
\bibliography{/home/kem/bib/kads,/home/kem/bib/methods,/home/oplan/html/work/ISAT/jkk/webpage/acp,/home/kem/bib/k_acq,/home/jkk/writing/ssm/checkland}
\newpage
\appendix
The repertory grid technique for knowledge acquisition Gaines93b is
derived from the personal construct theory of George Kelly Hinkle70. A
grid is drawn with each activity forming a separate column in the
grid. [9]
The rows are
labelled with attributes against which each activity can be classified on a
1-5 scale. Four of these attributes were provided from past experience; two
more, ``Analytic vs Synthetic'' and ``Evaluation required'' were
elicited
[10]
from Doug Holmes, who was the first expert with whom this technique
was used.
Each expert was then asked to fill in the grid with numbers between 1 and 5,
representing their opinion of the values of various attributes.
For example, Figure rgplxoo shows that, in Checkmate's opinion,
identifying campaign objectives and military objectives takes very little time
(1 =
Short), but requires considerable experience (4 = Fairly Much).
There is much useful information to be gained from this technique, by:
Ideally, each expert should be questioned on the criteria he has used for
filling in the repertory grid. However, the grids completed by Checkmate were
filled in remotely, so this questioning has only been performed for a few key
scores where the experts had differing opinions. Doug Holmes
filled in his grid interactively (i.e. with the knowledge engineer present and
occasionally prompting for information),
and his comments about the criteria which he used for
assigning values to attributes, gathered from the ``aside'' comments which
he made, are given below:
Repertory grids were eventually obtained from five experts; Doug Holmes, Joe
Roberts (a former member of Checkmate) and three current members of Checkmate
staff. The full set of grids can be seen in section appxrgallgrids. Doug and
Joe held the opinion that the Checkmate staff would be able to
provide more accurate values for the repertory grid than they could, so the
final analysis was done on a repertory grid which amalgamated the scores of
the three Checkmate staff (see figure rgplxoo). The Checkmate staff
largely agreed with each other on most of the attributes; where they
did not agree, they were asked to provide explanations. These explanations
often related to underlying assumptions; some of these explanations have been
incorporated into the descriptions of activities given below, and a few values
have been weighted according to the explanations given. The main area of
disagreement was on the Analytic vs Synthetic attribute; it was felt
that the knowledge engineer had given the Checkmate staff insufficient
explanation on the meaning of this attribute, and so it was excluded from
further analysis.
The results of the repertory grid technique were subjected to statistical
analysis (see Figure rgplxoxc). This analysis showed a strong
correlation between the scores
provided for Experience required and the scores provided for {\bf
Seriousness of mistake}; there was also a strong correlation between the
scores provided for Time required and the scores provided for {\bf
Evaluation required}. The former correlation suggests an underlying
philosophy, that it is more important to avoid serious mistakes than to
minimize the total number of mistakes; the latter correlation is to be
expected, since evaluation takes time. It
is usually superfluous to include two strongly correlated attributes in the
task model; Evaluation required has therefore been eliminated from the
task model. However, both Seriousness of mistake and Experience
required have been retained in the task model. This is done because the
experts made a number of aside comments about the seriousness of mistakes
which can be displayed with this attribute; while the level of experience
required is an easy statistic to acquire and verify. It is easy because
different levels of experience required correlate with the rank of the officer
required to perform an activity, and the correlation can be checked easily
using the heuristic used by Doug Holmes (see section appxrgcriteria).
The repertory grid technique was also applied to the activities which appear
in figures TaskStrucAirObj, TaskStrucTaskObj and
TaskStrucTargets, in order to see if useful information could be
obtained from this technique. Little analysis has been completed on these
repertory grids so far. An example of an ``expertise model'' level repertory
grid -- the one acquired from Doug Holmes -- is shown in Figure rgprdh.
Once the grid has been completed, it's possible to perform statistical
clustering on the value supplied, to see if there is any implicit
categorization of the activities reflected in the scores provided for each
activity.
Figure rgplxoxc shows the results of performing
statistical cluster analysis on the scores in the grid shown in Figure
rgplxoo; Figure rgpriclu shows the results of
cluster analysis on the grid shown in rgprdh. This gives some idea of
the (subjective) similarity
of activities on the attributes identified in the grid. The result of cluster
analysis is a ``taxonomic'' hierarchy, in which the ``classes'' are actually
nodes identifying the percentage of similarity between activities, or groups
of activities. For example, in Figure rgpriclu, the identification of
enemy Centers
of Gravity is carried out 3 times (when prioritizing Air Objectives, Task
Objectives and Targets); the latter two are scored identically (100\%
similarity) whereas the prioritization of Air Objectives only merits 79\%
similarity with these two.
It is often instructive to ask the expert why certain activities are
considered similar or different. In the example above,
Doug suggested that this phenomenon was due to
the fact that it's harder to identify Centers of Gravity at the first attempt;
once the task has been done once, at a high level, it is less difficult at
lower levels of detail. In another example, Doug was asked why ``Identify
Targets'' was so different from the other activities (see Figure rgpriclu). By
looking at the scores in the grid, it can be seen that ``Identify Targets''
is the only activity which requires a lot of time but does not require much
evaluation or experience. This observation led the knowledge engineer to
suggest that ``Identify Targets'' might be a suitable activity for automation
using conventional (i.e. not knowledge-based) computing; Doug replied that
such a task was already being undertaken.
Domain Knowledge
Knowledge acquisition using repertory grids
appxrepgridRepertory Grids
[9]
The repertory grid technique is normally
used for acquiring attributes and values of concepts. In this case, the
concepts are replaced by activities, in order to ascertain some
important information about these activities.
[10]
These attributes were elicited
using the triadic elicitation technique; choosing three domain items at random and asking the expert to specify any attribute on
which one of the three items differs from the other two.
Criteria used to fill in the grid
appxrgcriteria
Results
Repertory grids: expertise model level
Statistical analysis of repertory grids
appxrgstats
Full set of acquired repertory grids
appxrgallgrids
\newpage
The IDEF3 modelling technique
appxidef3
The following collection of IDEF3 diagrams represent the Air Campaign Planning process as elicited from a number of experts. The notation and benefits of this method are discussed in an accompanying document IDEF3.
Five processes are shown at the highest level. Each of these is decomposed into subprocesses which are related to their parent by the numbering system. This consists of a prefix formed from the parent UoB reference number, the number of the decomposition and a unique reference number.
Concurrency between subprocesses within a single decomposition is illustrated using asynchronous \& junctions. The fan-out junction indicates that both subprocesses must start, and the fan-in junction indicates that both of those subprocesses must complete before the next subprocess can initiate.
The decomposition of UoB 3 ``plan the air campaign'' refers to various briefings. These are shown as synchronous referents which indicate that the referent process (the briefing) must initiate and complete before the focus process is considered to be complete.
Finally the decomposition of UoB 5 ``evaluate air campaign'' uses exclusive OR junctions showing that if new policy and guidance has been received either the air campaign will cease or the air objectives will need to be reviewed as indicated by the unconditional Go-To referent, which loops the process back to 3.1.16 ``identify and prioritize air objectives''. When there is no new policy and guidance the air tasks will need to be reviewed, as indicated by the unconditional Go-To referent, which loops the process back to UoB 3.1.17 ``identify and prioritize air tasks''.
\caption{Preparing for an Air Campaign}
\end{figure}
\begin{figure}[ht] \psboxto(17cm;0cm){/home/tjl/ISX-IFD/i3tool/i3tool/docs/2-1.ps}$$
\begin{figure}[ht]
\end{figure}
\begin{figure}[ht]
\caption{Evaluating an Air Campaign}
\end{figure}
\newpage
This list of objectives has been derived from a document supplied by
Checkmate in November 1995, giving objectives which have been
defined in planning for actual military exercises.
This document describes these objectives using the following template:
Perform Action on Center of Gravity with optional modifier.
Some objectives are rephrased to enable them to fit this template.
The action and the Center of Gravity are highlighted by using small
capitals and teletype font respectively.
The code numbers at the beginning of each objective show which higher level
objectives are addressed by the lower level objectives; for example, air
objective B5.1 fulfils CinC objective B5.
Reduce Yellowland Orangeland Cooperative (YOC) to ensure regional
stability
Isolate and neutralize YOC military control on population
Deny use of electricity to YOC military structure.
Deny use of electricity to YOC population
Deny use of chemical products for the manufacture of weapons of
mass destruction.
Obtain sufficient Blue Forces for future offensive operations.
Permit safe access to national waterways for Blue shipping.
Deny use of national transportation networks leading to YOC
economic centers.
In this form, it can be seen that this is an infrastructure objective rather
than a national population objective.
Use C2W methodologies to influence YOC population.
This is a high level objective; in order to match the level of detail of the
other objectives, individual C2W methods should be specified.
Restore the sovereignty of B/G by fielding military forces.
Defend Blue forces Against Weapons of Mass Destruction
Attack naval transport ships which are capable of transporting
military equipment on national waterways.
These had not been sorted by Checkmate at the time of writing. Categorization
has been performed by the author of this document.
Where a air task falls into one category but services an air
objective in another category, it is categorized under the former. For
example, Destroy known NBC logistics support is categorized under
National Infrastructure, even though it supports the air objective {\em
Disrupt YOC Weapons of Mass Destruction Capability}, which is categorized
under Key Production.
\paragraph{YOC forces}:
\indent Destroy key national headquarters
Disrupt YOC reconnaissance/surveillance capabilities
Disable known NBC C3 capability
Disrupt C3I to frontline offensive units
Disrupt enemy control of air operations and (control of) air
defenses
Destroy key command centers
Destroy air defense C3I
Disrupt key command and control nodes
Disrupt TBM C2
Neutralize airborne C3 capability
Disrupt key C3 nodes
Destroy key YOC LADS C2 facilities
Destroy command centers \& comm nodes to disrupt YOC
political and military direction of armed forces
Destroy army, corps, and division HQs or isolate them
from subordinate units
Sever LOCs in support of GCC ground scheme of maneuver. Rephrased to:
Sever local command centers in support of GCC ground scheme of maneuver. Rephrased to:
Destroy coastal surface surveillance radar C2
Destroy key YOC LADS C2 facilities
Disrupt naval C3I
Disrupt Political Leadership of YOC Forces
Destroy Command and Control Facilities in the forward area
Destroy key YOC LOC's supporting forward troops
Render ineffective C2 from YOC leadership to ballistic missiles
\paragraph{Blue forces}:
\indent Provide battle management/C3I capability
Provide surveillance and reconnaissance of region
Destroy YOC intelligence collection/dissemination capability
Exploit CUWTF intel and targeting when tasked by the B/G C3
\indent Destroy known NBC research facilities
Destroy known NBC production facilities
Attrit military production capability
Disrupt electrical power supply to LADS and pol-mil C3I
Disrupt/destroy military vehicles, armor, and artillery
assembly \& repair facilities
Disrupt/ destroy remaining POL production and storage
Disrupt/ destroy remaining munitions and propellant
production and storage
Disrupt NBC production and storage capability
Disrupt nuclear reactor \& fuel/ore processing
Destroy YOC mining capability
Disrupt YOC Electrical Power Distribution
Destroy Naval Production Capability
\indent Disrupt YOC naval port operations
Destroy logistics/maintenance/supply areas
Disrupt SATCOM capability
Destroy known NBC logistics support
Destroy known NBC stockpiles and storage facilities
Disrupt electrical power grid
Destroy key naval communications nodes and EW/GCI
Destroy railroad transportation terminals and facilities
Destroy key bridges \& tunnels
Disrupt operations along LOCS/chokepoints
Destroy POL storage/distribution facilities
None given.
\paragraph{YOC forces}
\indent Attrit follow on forces
Attrit front line forces
Attrit enemy fighter/bomber force
Destroy key SAM sites
Destroy SAM sites threatening air operations throughout YOC
Disrupt maneuver and momentum of committed forces with CAS
Neutralize YOC 240/170mm artillery
Destroy remaining mech \& armor assets of 2nd echelon forces and
strategic reserves
Disrupt YOC SAM/AAA sites along coastal corridors
Destroy Silkworm missile/sites and storage
Disrupt/destroy SAM/AAA/GCI affecting insertion corridors and
drop zones
Render ineffective YOC target acquisition systems
Destroy landmines
Destroy key EW/GCI sites supporting YOC defense assets
Destroy coastal surface surveillance radar sites and C2.
Divided into two:
Destroy coastal surface surveillance radar sites is categorized
here; destroying the radar's C2 is categorized under Leadership
Neutralize YOC capability to utilize its aircraft and airfields. This is
a higher level objective, since ``capability to
utilize'' might encompass fuel, pilots, repair facilities, etc.
Destroy major YOC surface and sub-surface combatants and SOF
insertion platforms
Disrupt YOC Ground Forces With CAS
Destroy Tactical SAMs in YOC
Destroy Strategic SAMs in YOC
Destroy EW/GCI radars within 100 Km of the border
Disrupt YOC Fighter/Bomber Operations
Destroy Coastal Surveillance/Fire Control Radars
Destroy YOC SAM/AAA sites
Destroy Silkworm missiles/sites and storage
Destroy key EW/GCI sites supporting YOC defense assets
Disrupt YOC fighter capability
Disrupt/destroy SAMs on border, AAA near drop zones,
and EW/GCI threatening CUWTF insertions
Disrupt YOC SAM/AAA sites along coastal corridors
Disrupt YOC bomber capability
Disrupt maneuver and momentum of committed forces with CAS
Disrupt movement \& maneuver into M-K corridor. Rephrased to:
Disrupt movement \& maneuver of forces into M-K corridor
Attrit forces in Wonchor corridor
Disrupt/destroy 240mm/170mm artillery beyond the FSCL
Disrupt 240mm/170mm artillery inside the FSCL
Disrupt mechanized and armored formations between FLOT and FSCL
Destroy YOC SOF infiltration aircraft
Destroy major YOC surface and sub-surface combatants and SOF
insertion platforms
Destroy SAMs beyond 100km of the DMZ
Assist in holding defense north of capital city by destroying YOC
non-hardened artillery and vehicles
Attrit Naval Bases and their Employment Capability
Destroy enemy OCA assets
\paragraph{YOC supply, storage \& repair facilities}
\indent Destroy TBM launchers, storage, and support
Disrupt TBM shipment/transshipment
Disrupt resupply of naval POL, munitions, \& spares
Destroy ammo storage
Destroy naval ship repair \& resupply facilities
Disrupt naval surface craft bases, support facilities, and naval C3I.
This objective has been divided into 3 objectives:
Disrupt naval surface craft bases and Disrupt support
facilities are categorized under Fielded forces, while
disrupting naval C3I is categorized under Leadership.
Disrupt marshalling areas and sustainment capability beyond
the FSCL
Disrupt marshalling areas, supply, and corps C2 beyond FSCL
\paragraph{Blue forces}
\indent Employ passive defensive measures. Rephrased to: Assign and
Provide military equipment which is capable of passive defense.
Provide ground/naval point defense for protection of Blue COGs
from air \& TBM attacks
Conduct CAS in support of the Rear Area Security Forces
Support B/G ground scheme of maneuver and deception plan through AI.
Rephrased to: Provide AI to support B/G ground scheme of maneuver
and deception plan.
\paragraph{High level objectives}
The following were listed as air tasks, but are more appropriately
categorized as either CinC objectives or Air Objectives.
\indent Disrupt YOC ability to employ weapons of mass destruction (WMD). This
is almost identical to Air Objective B8.2, and it belongs at the Air
Objectives level.
Disrupt Employment of Weapons of Mass Destruction by YOC Forces
Disrupt military activity in the area of the planned NEO
Destroy command centers and comm nodes to disrupt YOC political direction of armed forces
\paragraph{Unclassified}
\indent Destroy RADRELs -- unknown abbreviation
Employ SIGINT collection assets -- unknown abbreviation
Employ HVAA assets/Provide adequate HVAA protection -- unknown abbreviation
The centers of gravity which have been elicited from the sets of objectives
have been categorized into hierarchies. These hierarchies are shown below.
The aim of producing these hierarchies is to permit a near-exhaustive approach
to identification of centers of gravity. By working from the top of a
hierarchy downwards, planners can easily identify if they have considered all
relevant categories of centers of gravity.
The 5 top level centers of gravity in these hierarchies are Leadership,
Key Production, National Infrastructure, National Population
and Fielded Forces. These correspond to Col. Warden's ``5 rings" approach
to identification of centers of gravity. The approach which has been taken
to developing these hierarchies is top-down extrapolation; that is, if there
are several centers of gravity at the same level of a hierarchy, and one of
them is decomposed in a certain way, then the others are assumed to be
decomposable in the same way. An example of this can be found in Figure
cginf1, which shows centers of gravity connected with
transportation. Since road, rail, inland waterways, coastal shipping and civil
air transport are all transportation networks, then
the hierarchy assumes that the key centers of gravity for all these
types of transportation can be categorized as nodes, choke points
or segments.
A key component of the hierarchies which
contributes to the goal of identifying all relevant centers of gravity
is the identification of intra-hierarchy links.
These show where a center of gravity in a different part of the hierarchy is
relevant to the current center of gravity. The name of the related hierarchy is
displayed in the bottom half of the CoG node. For example, one form of
communication is by newspapers and printed media; the distribution of these
requires transportation. A planner examining the segments of the
newspaper communication network would therefore be directed to look at the
centers of gravity for the appropriate type(s) of transportation.
Following these intra-hierarchy links may lead to the
identification of unexpectedly relevant centers of gravity. To take an example
based on real life, a planner who was attempting to prevent a large army of
tanks from invading would examine the hierarchy for Fielded Forces, and
would discover ``Logistics'' as a center of gravity. In this category, he
would be invited to consider Ammunition, Fuel, Spare Parts
and General Munitions. On examining Fuel, he might decide that fuel {\bf
storage} is a potential center of gravity; but not only is it difficult to
attack, it is also an inadequate supply for a large army of tanks. This
inadequacy suggests that the other possible source of fuel -- a supply line
-- should be considered.
[12]
Here an intra-hierarchy link applies; the fuel is either supplied by transport
vehicles (in which case a link must be made to National Infrastructure:
Transportation) or, as in
this case, it is supplied by pipeline, in which case the appropriate starting
point is National Infrastructure: Fuel. Since fuel pipelines form a
network, then nodes, choke points and segments must be
considered. The segments in a fuel network are pipelines; it turns out that
there are only 5 pipelines used for pumping fuel to these storage areas, which
makes the pipelines a possible center of gravity. However, fuel pipelines are
hard to attack and easy to repair. The nodes in the network are the input
fuel plants and the storage areas, which are either too heavily defended or
too far away to consider. The consideration of choke points, however, leads to
the identification of three (undefended) pumping stations at a point where the
gauges of the fuel pipes change, thus ensuring that all fuel is routed through
these three stations.
It would seem sensible (if time is available)
for the planners to analyze Blue centers of gravity to
the same level of detail as hostile and adjoining centers of gravity (if possible), to the level
of identifying likely targets for any hostile and adjoining planners who might be conducting a
similar exercise.
The actions listed here are those found in air objectives (whose format is
``Perform action on center of gravity with modifier'').
The actions identified are listed below. The observations which were made on
actions are likely to be superseded by current discussions, so have not been
included in this document.
The actions identified are as follows:
\newpage
Many CinC objectives and Air objectives, and some air tasks, have
associated modifiers. These modifiers may be:
Lists of identified modifiers can be seen in table CinCmodifiers and
table AirModifiers.
Domain knowledge for Air Campaign Planning
List of objectives
appxobjectives
CinC objectives
Leadership
Key Production
[11]
The term ``electrical production", which appears in the Air Objectives (e.g. B2.1),
is more general than ``primary electrical sources". However, ``electricity" is a
more general term still, which is at the same level as ``petroleum products".
National Infrastructure
National Population
Fielded Forces
Leadership
Key Production
National Infrastructure
Fielded Forces
Leadership
Key Production
National Infrastructure
National Population
Fielded Forces
Centers of Gravity
Centers of Gravity
[12]
In fact, there are two other possible sources of fuel; direct
access to a fuel production plant, and siphoning it from other vehicles.
The former is unlikely to avoid notice, and the latter is
infeasible for a large army, even if they were not using specialized
fuel.
Observations
[13]
This assumes that deploying a force refers to the movement of a force into
the battleground, as opposed to allocating new
units to the theatre.
No air objectives are specified for national population. This action is
specified because neutralize appears in the CinC objectives, and so an
analogy can be drawn with the Leadership and Key Production
objectives.
Geographical | |
---|---|
US citizens | in the region |
US forces | in the region |
YOC aggression | against B/G |
YOC forces | north of Desired Area |
B/G | (a geographical modifier implicit in the CoG) |
Temporal | |
YOC economic centers | |
Categorical | |
YOC political control | YOC armed forces | YOC armed forces |
YOC political control | YOC population |
YOC military control | YOC population |
primary electrical sources | YOC population |
petroleum products | YOC population |
national television systems | YOC population |
national radio systems | YOC population | YOC population |
national roadways | Transport of military equipment |
national railways | Transport of military equipment | Transport of military equipment |
national roadways | Transport of goods |
national railways | Transport of goods | Transport of goods |
national communications networks | Transmit military information |
national television systems | Transmit military information |
national radio systems | Transmit military information | Transmit military information |
YOC petroleum production | supporting warfighting effort |
chemical products | for the manufacture of weapons of mass destruction. |
national waterways | for Blue shipping. |
national transportation networks | leading to YOC economic centers. |
Blue forces | Against Weapons of Mass Destruction |
\begin{table}
Geographical | |
---|---|
Temporal | |
Categorical | |
YOC political control | YOC armed forces |
YOC military control | YOC armed forces |
electrical facilities | YOC armed forces |
petroleum production | YOC armed forces |
chemical production? | YOC armed forces |
YOC political control | YOC population |
YOC military control | YOC population |
electrical production | YOC population |
petroleum production | YOC population |
chemical production | YOC population |
naval transport ships | which are capable of transporting military equipment on national waterways. |
command and control | YOC Air/Land/Sea forces |
Capability | |
(Blue) forces | capable of deterring YOC aggression |
(Blue) forces | capable of supporting NEO |
\newpage
The CommonKADS methodology
CommonKADSAppendix
The CommonKADS organizational model recommends examination of an organization
from five major perspectives:
Each perspective is represented by a single diagram, or by text.
These five perspectives can be combined into cross-products which provide
the most useful information. For example, the CommonKADS Organizational Model
was used to model a Social Security department; a cross-product of activities
and structure was produced which highlighted an area of inefficiency, because
one of the activities (archiving) was being performed by three different
divisions of the department deHoog93.
The process of domain familiarization also suggested that some aspects of the
organization surrounding ACP -- in
particular, power/authority relationships -- would benefit from being
represented in more detail than the CommonKADS Organizational Model currently
supports. It was decided that the multi-perspective approach to organizational
modelling would be maintained, but that the perspectives would be altered to
permit the representation of rights of access to resources and
information, and the representation of who was responsible for performing
which activities.
This distinction was derived from the ORDIT
project which is intended to support organizational requirements definition
Dobson94. The result was that a set of perspectives were developed
based on three basic entities: activities, agents and
resources. Figure richmodel shows the perspectives which were used, and
how they were combined.
The Task model shows the tasks carried out in the course of a
particular process.
If the organizational model indicates a particular function which might
usefully be automated, a task model can be produced which provides a detailed
description of the tasks which carry out that function. The task model may
also identify the inputs and outputs of each process (or task), and the
decomposition of tasks into more specific sub-tasks. Its purpose is to
allow identification of tasks which could usefully be performed by an
automated system, or by a program and a user working in conjunction.
A typical task model is shown in Figure fg:taskmodel, using the
graphical format which was originally specified in deGreef92. The model
represents the tasks involved in the preparation of a meal; such a model might
be used by a large restaurant or a hotel which was considering a
reorganization of its business.
\begin{figure}[hbtp]
In this diagram, the boxes represent tasks; the arrows represent inputs and
outputs of tasks; the lighter lines show the decomposition hierarchy of tasks;
and the shading indicates those tasks which are worth considering for
implementation using a computer system.
The Agent model represents the capabilities required of the
agents who perform a process, and constraints on their performance.
The agent model represents all the agents which participate in a problem
solving process. It is often useful to develop two agent models: one which is
based on the task model, showing which agents are currently involved in
performing particular tasks, and one which predicts the agents and
capabilities required to carry out future tasks.
An example of an agent model, using the graphical format suggested by the
CommonKADS Workbench, is shown in Figure fg:agentmodel.
The Communication model shows the communication required between agents during
a process; it may also specify the form of messages, and specify who takes the
initiative in a transaction.
The communication model indicates all the transactions which take place
between different agents. Normally, this will comprise transactions
between a knowledge based system and other agents. It is therefore often convenient to combine
the Communication model with the Agent model.
An example of an communication model, using the graphical format suggested in
the KADS-II report on the CommonKADS Communication Model (Waern94b) is
shown in Figure fg:commodel.
The Expertise model is a model of the expertise required to
perform a particular task. This
model is divided into three components:
The domain knowledge in the model of expertise represents the declarative
knowledge which has been acquired. CommonKADS suggests that each item of
declarative knowledge is classified into one of the four categories outlined
below:
Once items of domain knowledge have been classified, they can be used in
domain models, which show relations between different items of
knowledge. For example, a domain model might
show all acquired examples of one concept causing another; or it
might show a taxonomic hierarchy of concepts, connected to each other by {\bf
is-a} relations. Figure dommodelps shows an example of a domain model; this model
represents indicative relationships between certain symptoms of a
manufacturing machine, and possible faults with that machine.
CommonKADS also recommends that the domain knowledge is represented at a more
abstract level, at which generic statements about the structure and contents
of domain models are expressed. The terms used at this abstract level are
stored in a model ontology, and the statements at this abstract level
are known as model schemata. This abstraction is intended to form a
basis for re-using domain models in different problem solving situations.
The domain knowledge in the CommonKADS Expertise model therefore consists of a
domain ontology (i.e. a collection of classified terms) and a number of
domain models which represent relations between items from the domain
ontology. In addition, it is recommended that an abstract view on the domain
knowledge is created.
The second subdivision of the Expertise Model records knowledge about
inference which may be performed in order to solve a problem. This
information is represented in inference structures, which are diagrams
showing how various inferences and knowledge roles link together
to perform problem solving.
Both KADS-I and CommonKADS provide a library of generic inference structures,
indexed by the type of task which is being performed (classification,
diagnosis, configuration, etc.). These generic inference structures can be
used as a starting point for developing an inference structure for a
particular application.
An example of an inference structure can be seen in Figure fg:infstruc.
In this inference structure, machine fault diagnosis is seen as a process of:
The last four steps are performed iteratively until only one hypothesis
remains, or until no further tests are available. This inference structure
therefore represents the ``Sherlock Holmes'' approach to diagnosis: by
eliminating the impossible, whatever remains must be the truth.
It can be seen that knowledge roles are represented as boxes, and inference
steps as ovals; arrows link knowledge roles with inference steps. Variations
on the basic graphics include inference steps with a ``double oval''
(indicating that this inference step is expanded into more detail in a lower
level inference structure) and bold outlines on knowledge roles (which
indicate that a knowledge role is static; that is, the knowledge it
represents is not changed in any way during problem solving.
The task level of the model of expertise is normally represented as a
graphical hierarchy. However, textual representation is also possible, and can
be more informative; see Kingston93b for an example.
Task knowledge differs slightly between KADS-I and CommonKADS, because KADS-I
has an explicit strategy level of knowledge, whereas CommonKADS considers
strategic knowledge (now known as problem solving knowledge) to be
orthogonal to the domain-inference-task decomposition of the Expertise Model.
In both cases, however, the task
knowledge which needs to be modelled consists of various tasks which have to be
performed and actions which have to be achieved, and breakdowns of these tasks
into subtasks. In addition, CommonKADS has an explicit category for tasks
which pass information to or from the problem solving process (known as {\em
transfer tasks}); a selection of problem solving methods
(pre-defined generic task structures); and a detailed specification of how
tasks should be defined.
An example of a task structure can be seen in figure fg:taskstruc.
This diagram represents a decomposition hierarchy, showing the tasks which
must be performed in order to diagnose faults in a machine.
CommonKADS also provides definitions for a library of problem solving
methods i.e. pre-defined task structures for certain tasks. However, this
``library'' currently contains very few problem solving methods (cf.
Kingston93).
The Design model culminates in the design of a knowledge based
system to perform all or part of the process under consideration.
The design process in CommonKADS is broken down into three stages:
While it is possible to represent the Application Design (at least) in
diagrams, CommonKADS does not recommend any graphical format for the Design
Model; instead, it is expected that the different stages of this model will be
represented using text. However, during the course of a recent project, a
graphical representation for the Design Model was used (see figure
fg:designmodel); the four columns of nodes represent:
Organizational Model
Enriching the CommonKADS Organizational Model for the ACP domain
Task model
Agent Model
Communication Model
Expertise Model
Expertise Model: Domain Level
CommonKADS
also supports attributes, which are properties which can belong to
multiple concepts, and which are defined independently from concepts for
convenience. Weight might be an example of a CommonKADS
attribute.
Expertise Model: Inference Knowledge
Expertise Model: Task Level
TaskandStrategy
Design Model