Multi-Perspective Modeling of the Air Camaign Planning Process

1 Introduction

This paper describes work performed to acquire knowl­ edge about, and produce models of, the USAF Air Cam­ paign Planning (ACP) process. The aim of this work was to produce a set of "knowledge models" which re­ searchers in the area could refer to, rather than having each of them interview the expert planners.

It was decided that the models which were produced should be multi-perspective models; that is , a variety of models would be produced, each containing a particular type of knowledge about the air campaign planning pro­ cess (declarative, procedural, communications, etc), and thus representing the ACP process from a number of dif­ ferent viewpoints. The chief benefits of multi-perspective modelling are that it is easier to ensure complete acqui­ sition of knowledge of each type, easier to maintain the knowledge, and easier to re-use individual models if an­ other application should be developed.

The basis for this approach was the CommonKADS methodology for modelling ore;anisational and expert knowledge. CommonKADS lSchreiber et al., 1994; Breuker & van de Velde, 1994] is a collection of struc­ tured methods for building knowledge based systems, analogous to structured methods for software engineer­ ing; as such, it provides an enabling technology for the analysis of acquired knowledge and the design of knowl­ edge based systems. It was developed between 1983 and 1994 on two projects funded by the European Commu­ nity's ESPRIT program, and has recently been identified as an technology with much potential by the Strategic Directions For Computing Research working group in North America [Computing AI Working Group, 1996].

For analysis of any knowledge-based application, Com­ monKADS recommends the development of one or more of the six models described below. The models, which are represented using node-and-arc diagrams, relate to each other as shown in Figure 1.

• An organisational model to represent the processes, structure and resources within an organisation;
• A task model to show the activities carried out in the course of a particular process;
• An agent model to represent the capabilities re­ quired of the agents who perform a process, and

constraints on their performance;

• A communication model to show the communication required between agents during a process;
• An expertise model, which is a model of the ex­ pertise required to perform a particular task. This model is divided into three components:
• declarative knowledge about the domain;
• the inference processes required during problem solving;
• a hierarchical classification and ordering of the inference processes.
• A design model, which culminates in the design of a knowledge based system to perform all or part of the process under consideration.

In order to represent the ACP process to a sufficient level of detail for other researchers, it was decided that the Organisational, Task and Communication models would be required; the Expertise model was also par­ tially developed. The purpose of this paper is to de­ scribe the development of these models, with an empha­ sis on the use of different modelling techniques within a CommonKADS framework to represent the different perspectives. The paper concludes with discussion of a suggested framework for classifying and applying mod­ elling techniques to multi-perspective modelling.

2 Knowledge acquisition

Knowledge acquisition was initially carried out using in­ terviews. These interviews provided much useful knowl­ edge, and also highlighted the existence of a number of relevant documents, from which a lot of knowledge was acquired. Two other knowledge acquisition techniques were also used: analysis of protocols acquired during a sample planning scenario provided useful information about the priorities, ordering, and necessary information for the planning process; and the repertory grid knowl­ edge elicitation technique [Gaines & Shaw, 1993] was used at a later stage to determine which activities within the planning process might benefit from knowledge based system support.

The knowledge that was acquired showed that air cam­ paign planning is hierarchically organised. When a crisis occurs, the Commander in Chief (CinC) provides plan­ ning guidance to the Joint Forces Commander (JFC) . This guidance is communicated to the component com­ manders (e.g. the Air Component commander) , who will in turn communicate the guidance to the air campaign planners . Based on the guidance, the planning staff will take between 3 days and 1 week to build a plan that may be executed. The acquired knowledge also showed that certain documents (such as the Master Attack Plan and the Air Tasking Order) form the outputs of key activi­ ties, and constitute a major method of communication within the planning process.

3 CommonKADS models

The acquired knowledge was then classified into appro­ priate CommonKADS models.

3.1 Organisational model

The CommonKADS organisational model [de Hoog et al., 1993b] is a collection of diagrams, each taking a dif­ ferent perspective on an organisation. CommonKADS recommends and suggests formats for diagrams of the organisational structure, activities, power/ authority re­ lationships and various resources. These models analyse each type of knowledge individually; "cross products" can also be developed which combine the knowledge from two different perspectives.

There may be various reasons for developing an organ­ isational model:

• The model may be intended to describe the organi­ sation in a way which facilitates identification of or­ ganisational needs and opportunities. By giving de­ tailed but separate description of the activities, the structure which contains agents who perform activ­ ities, and the resources required for activities, it be­ comes easier to identify insufficient or excessive con­ straints on agents, under- or over-resourcing, and other potential areas for improvement.
• By emphasising knowledge-based activities in the modelling, this model can be used as a basis for knowledge management within an organisation. Knowledge management , which is a growing area of interest, involves surveying, categorising, analysing and synthesising knowledge-based activities, codify­ ing and organising knowledge, appraising and evalu­ ating knowledge and related activities, and deciding how to leverage, apply and control the knowledge [Wiig, 1993].
• The model can be used as part of a feasibility as­ sessment of a proposed knowledge based system. A good example of this can be found in [de Hoog et al. , 1993a], which describes a feasibility study into de­ veloping a KBS to support decision making within

a social security department, in order to reduce the time taken to process social security applications. A "cross product" of the organisational activities and organisational structure showed that decision mak­ ing was distributed among several departments, and only occupied a small proportion of the total pro­ cessing time for an application.

• The model may simply be required to provide a comprehensible , high level overview of an organisa­ t ion for specialists who work in a narrowly focused area, and who need to know how their work relates to the rest of the organisation.

The modelling of air campaign planning was carried out for the final reason : to provide an overview of the air campaign planning process to ARPI researchers who are developing systems to perform knowledge-based plan­ ning and other tasks . The organisational model was also adapted according to the demands of the domain; specif­ ically, the representation of power/ authority relation­ ships was considered superfluous by the experts, which is unsurprising in a model of a military organisation, where all authority is inherent in the organisational structure.

The resulting organisational model consisted of dia­ grams of activities (such as Figure 2), agents within an organisat ional structure, and resources. These were then combined to produce "cross products"; Figure 3 shows an early version of the cross product between activities and resources.

Key:

Solid link Dashed link the first activity precedes the second there is an information flow from the first activity to the second.

With its combination of perspectives, the Com­ monKADS Organisational model provides a good overview of an organisation and its activities. How­ ever , there is a need for a more detailed analysis of the Air Campaign Planning process in order to supply re­ searchers and developers of potential automated plan­ ning and decision support tools with sufficient informa­ tion on where automated support is required, and there­ fore on where their tools might be used. As a result, it was decided that the CommonKADS Task and Commu­ nication Models needed to be developed as well.

Key:

Labelled link

Diamond Rounded rectangle

3.2 Task Model

The CommonKADS Task Model [Duursma, 1993] ex­ pands one of the organisational activities identified in the organisational model into a more detailed view of the processes required to perform that activity. The under­ lying assumption is that this organisational activity has been identified as a source of an organisational weakness or opportunity, and so the activity should be investi­ gated in more detail, with a view to automating certain sub-processes, or improving the knowledge management of sub-processes in other ways.

CommonKADS recommends a format for Task model diagrams . CommonKADS'recommended representat ion has the benefits of simplicity and clarity, but certain key information is relegated to textual annotations rather than being represented graphically. The representation of processes has been addressed by a number of differ-· ent methods and techniques, each of which has its own strengths and weaknesses; for this project , where the pri­ mary aim was to communicate detailed information to other researchers, it was decided that CommonKADS' representation for the Task model was not adequate. The Process Flow Network recommended by the IDEF3 method was used instead.

IDEF3 is a process capture technique which was de­ signed to be tolerant of incomplete and inconsistent de­ scriptions, and to be flexible enough to deal with the in­ cremental nature of the information acquisition process. It provides both a process-centred view of a system, via

the activity produces consumes uses/modifies the resource Passive resource Activity the Process Flow Network, and an object-centred view of a system via the Object State Transition Network.

A process flow network displays a sequence of Units of Behaviour (UOB) which represent activities, actions, processes or operations. These are linked together by precedence arcs. Where the process flow diverges (fan­ out) or converges (fan-in) junction boxes are used. Junc­ tions are of the AND, OR or Exclusive OR type and can be synchronous or asynchronous. This notation may impose timing constraints on the process flow. For ex­ ample, a synchronous fan-in junction indicates that the incoming processes must complete simultaneously before the next UOB can begin.

In addition to UOBs and junctions, process flow net­ works can include referents, elaboration forms and UOB decompositions. Referents are used to indicate context­ sensitive information and may refer to any other type of UOB such as an elaboration form, another process flow network, an object state transition network, an entirely different scenario, a note, or act as a GO-TO within the network. In some cases referents may impose tim­ ing constraints on the process so there is the option to be synchronous or asynchronous as needed. An elabo­ ration form holds specific textual information for each UOB such as the object used by it, constraints acting on it , facts about it and a description of it. Decompositions enable each step of the process to be broken down into more detailed process descriptions, allowing descriptions to be held at varying levels of abstraction. This is indi­ cated on the diagrams by a shadow on the parent UOB box.

An example of an IDEF3 process flow network can be seen in Figure 4.

3.3 Agent and Communication Models

The CommonKADS Agent and Communication models support the Task model by identifying other informa­ tion about the sub-processes being modelled. The Agent model represents the capabilities and skills of the agents (staff, clients, or computer programs) who perform each activity within a sub-process; the Communication model represents all communication which must take place be­ tween agents in order for a process to be completed.

One of the primary uses of the Agent model is to determine which roles can be performed by a human , which by a computer, and which by a human and com­ puter working together. As this was not a major purpose of the modelling exercise, it was decided that an Agent model was not required. A Communication model was required, however, because effective transfer of informa­ tion from one person or working group to the next is an important factor in the completion and efficiency of the planning process.

As with the Task model, CommonKADS' recom­ mended format for communication modelling (described in [Waern et a/. , 1994]) was not the richest technique available, and it was decided that a model rich in detail was required for this project. Role Activity Diagrams (RADs), a representation developed by a UK consul­ tancy [Ould, 1992-3], were used instead . RADs are de­ signed to represent all communication transactions suc­ cinctly; they represent the initiator of each communi­ cation; they link communication to activities, thus pro­ viding an explicit link with the Task Model ; and they allow textual annotations to represent details. Part of the RAD which was developed for Air Campaign Plan­ ning can be seen in Figure 5.

3.4 Matching modelling techniques to perspectives

An important observation which was made was that IDEF3 Process Flow Networks and RADs could be used without modification to represent the CommonKADS Task model; this implies that these techniques model a single perspective on an organisational process. If this observation can be extended to other modelling tech­ niques, then it should be possible for organisations to use CommonKADS as a modelling framework within which existing techniques can be used where appropri­ ate, and CommonKADS' recommended techniques can be used for perspectives on knowledge which are not cov­ ered , or inadequately covered, by existing techniques. This would allow introduction of a CommonKADS ap­ proach without discarding work previously performed using other modelling techniques, and would reduce the learning curve for CommonKADS.

However, there is currently no systematic way of se­ lecting a suitable technique to represent a particular per­ spective without having detailed knowledge of the capa­ bilities of every possible technique.

As part of the ACP modelling effort, the authors of this paper met with a "modelling cluster" of re­ searchers within the overall project who were inter­ ested in wider modelling issues. At the suggestion of one of the participants , the Sowa/Zachman framework for Information Systems Architecture [Zachman, 1987; 1992] was proposed as a basis for classification of mod­ elling techniques.

The Information Systems Architecture (ISA) frame­ work, which can be seen in Figure 6, classifies infor­ mation and/or systems on two dimensions: perspective and level of abstraction. The six categories in the per­ spective classification are represented succinctly by the words What , How, Who, When, Where and Why. In other words , the ISA framework is suggesting that, to model an information system completely, it is necessary to determine what information will be used; how it will be processed; who will use it; when in the process each item of information is needed; the location at which each piece of information is needed; and the underlying strat­ egy. These perspectives map closely to the perspectives recommended by CommonKADS:

• the Task model shows how information is processed;
• the Agent model shows who handles the information
• the Communication model shows where the infor­ mation is needed
• part of the Expertise model defines the flow of con­ trol that specifies when activities occur
• both the Organisational Model and the Expertise model have components describing what informa­ tion needs to be processed.

CommonKADS does not have an explicit "strategy" per­ spective; however, the library of "problem-solving meth­ ods" within the Expertise Model, and some aspects of the Design Model , are considered sufficient to sup­ port and represent why a particular way of representing knowledge has been chosen.

The second classification which appears within the ISA framework is level of abstraction. The framework suggests that each perspective should be modelled at six levels of abstraction, ranging from the scope of the sys­ tem through enterprise, system and technology models to components and functioning systems. These terms are intended to be generic terms which can be customised for each particular application; for example, in the de­ sign and construction of a business system or building, the six levels of abstraction might correspond to the con­ siderations of the planner, the owner, the designer, the builder, the sub-contractor and the user. By combin­ ing these different levels of abstraction with the different FOCUS

'"'""""

""""

Figure 6: The Information Systems Architecture frame­ work

perspectives on information, 36 possible classifications are created.

The four intermediate levels of abstraction identi­ fied by the ISA framework have direct correspondence with levels of abstraction identified by CommonKADS. The enterprise level corresponds with the Organisational Model, the system level with the Task, Agent & Commu­ nication models, the technology level with the Expertise Model, and the component level with the Design Model. The scope level, which defines what is inside and out­ side the boundaries of the information system, is implic­ itly represented by the presence or absence of knowledge items in CommonKADS models, while the functioning system level clearly corresponds to implemented KBS systems.

From this analysis, it can be seen that the Com­ monKADS approach to knowledge modelling can be mapped to the perspectives and levels of abstraction rec­ ommended by Sowa and Zachman in their framework for Information Systems Architecture. Given that Com­ monKADS is a proven enabling technology for KBS de­ velopment, this analysis suggests that:

• CommonKADS could usefully be extended in cer­ tain areas to increase its coverage of the framework. Some of this work is already taking place; for exam­ ple, the Communication model was originally seen as a way of modelling communication at the system level in order to identify communication bottlenecks and difficulties, but has been applied at the technol­ ogy level (e.g. [Kingston, 1992] because it provides a useful tool for modelling inter-system communi­ cation, and for defining requirements for user inter­ faces).
• Other techniques could be used in conjunction with CommonKADS, to augment or extend its capabil­ ities. The benefits of using known techniques in conjunction with CommonKADS include reduced learning curves, richness of representation, and re­ use of existing models. This project has shown how

IDEF3 Process Flow Networks and Role Activity Diagrams can be used to augment certain aspects of CommonKADS modelling; it is not difficult to imagine circumstances where knowledge modelling would benefit from representation of the what per­ spective at the system level , which could be accom­ plished using IDEF3's Object State Transition Net­ works, or other techniques.

• The ISA framework could be used to inhibit tech­ niques from being used where they are not appropri­ ate. There is a danger that the known technique will be over-used, because people who are familiar with a technique believe that they can "hack" a solution; however, classifying techniques using the ISA frame­ work promises to identify techniques that should be appropriate for modelling particular types of knowl­ edge, as well as making explicit the limits of these techniques.

3.5 Summary

The CommonKADS methodology is an enabling tech­ nology for the analysis and design of knowledge based systems. It recommends analysis of knowledge by pro­ ducing mutiple models showing individual perspectives on knowledge, and this multi-perspective approach is one of its main strengths. CommonKADS has proved to be very helpful for producing a well-defined model of air campaign planning; however, because of the richness of models required, CommonKADS was augmented with alternative modelling techniques that are able to replace the CommonKADS modelling techniques for certain per­ spect ives.

The Sowa/Zachman framework for Information Sys­ tems Architecture takes a similar multi-perspective view on the representation of information and knowledge to the approach taken by CommonKADS. The ISA frame­ work is capable of identifying specific areas where Com­ monKADS can be improved; if a suitable classification can be agreed, then there is potential for the ISA frame­ work to identify modelling techniques which are suitable for representing different types of knowledge.