School of Creative Technologies (CT)

Structuring Task Knowledge into CommonKADS Specifications for Generating Soar CGF Models

Daniel J. Allsopp
Tony Kalus

Alan Harrison

Colin Sheppard

ABSTRACT

Soar is not a particularly easy language to program. One of the complications of Soar programming arises from the fact that the programmer not only has to understand the Soar architecture and syntax, but must also organize the often complex knowledge being encoded in the model at the same time. These tasks may be partitioned by separating knowledge acquisition and the organization of acquired knowledge from the coding process. CommonKADS is a de-facto methodology for deriving ‘knowledge’ level specifications of problem solving tasks independent of implementation language. The use of CommonKADS as an intermediary to deriving Soar code is demonstrated in this paper. CommonKADS is used to produce Computer Generated Forces (CGF) task specifications which can then be transformed into Soar. The Soar code produced may not be particularly efficient. However, this approach has been shown to work in principle for selected task specifications, and may provide an alternative approach to generating Soar and other CGF language code which might lend itself to automation.

1. Introduction

Soar programming is recognized by non-experts to be something of an art. One of the complications in producing Soar code stems from the fact that the programmer not only has to understand the architecture and syntax of Soar, but must also organize the often complex knowledge being encoded in the Soar model at the same time. By separating the knowledge acquisition and knowledge structuring process from the Soar coding, each of these tasks may be focussed on in turn. An attempt at making Soar programming more accessible to programmers using this approach was made by Yost with the Task AcQuisition Language (TAQL) [1]. However, the Soar ‘Problem Space’ concept is central to TAQL, as knowledge is organized into problem spaces and then the script-like TAQL language is used to generate these problem spaces, and then to generate Soar code.

Although TAQL was potentially useful, it has not had wide appeal for a number of reasons:

• TAQL is a Lisp-based system produced at a time when programming trends were moving away from Lisp.
• TAQL can only be used to generate Soar code.
• The organising of knowledge into problem spaces has draw-backs, as many knowledge engineers and programmers are unfamiliar with problem spaces and how to structure them. On the other hand, tasks and task specifications are familiar terms within the CGF developer community – c.f. the Modular Semi-Automated Forces (ModSAF) ‘task-frame’.

Within the CGF community, it would nevertheless still be useful to have a high level CGF language that compiles into a range of cognitive architectures such as Soar [2], ACT-R [3] and JACK [4]. CommonKADS differs from TAQL in a number of respects. It is a ‘lingua frank’ for task-based knowledge level modelling independent of specification language [5, 6, 7]. CommonKADS specifications can be used to produce intelligent systems in a range of programming languages [5]. The CommonKADS specifications themselves are versatile; they are represented as ASCII text which may be stored in text-files, databases or even in the eXtensible Markup Language (XML) format [8].

This paper documents the use of CommonKADS as an intermediary to deriving Soar code only, although we have used the same approach to derive JACK code [8]. This approach cannot avoid the need to understand and learn the target cognitive architecture language and syntax – i.e. unlike TAQL, we have not developed fully the code generation components to convert CommonKADS representations into CGF code. In addition, the knowledge engineer and/or developer must understand and use the CommonKADS methodology for task specification. However, this approach separates knowledge acquisition and task specification from CGF implementation, providing task specifications that may be reused. We do not make claims about the efficiency of the code produced from CommonKADS specifications. But this approach has been shown in principle to work for selected CGF tasks, and may provide an alternative approach for generating CGF in Soar and other cognitive languages which might eventually be semi-automated.

2. Background

This research has developed from an initiative to find a way of reusing acquired doctrinal task knowledge for CGF implementation. The research programme called ‘Reducing the Cost of Acquiring Behaviours’ (RCAB) was set up by the Defence Evaluation Research Agency (DERA) in the UK in 1998 and had as its aim, the development of an architecture for:

• Automating CGF task knowledge acquisition [9].
• Storing military task knowledge in an implementation independent format [10, 11, 8].
• Automating the process of generating CGF code from stored military tasks [12].

The RCAB project itself is described in detail in [8]. Aspects of the RCAB architecture, such as the generation of human task analyses for use in simulation resemble certain aspects of the APEX project [13], although RCAB is not as mature. However, there are a range of commercially available agent development architectures that may be used to partially automate the generation of agent code from knowledge level task specifications [14, 15, 16].

2.1 Research Aims and Target Audience

The aims of the research described in this paper form a sub-set of the RCAB project goals, and are summarised as follows:

• To show that CommonKADS can be used to specify CGF military tasks.
• To show that Soar models can be directly and easily derived from these specifications.

The purpose of achieving these aims is to determine the suitability of CommonKADS as a representation of reusable task knowledge for generating CGF code. We believe that this approach may be of interest to knowledge engineers, developers and project managers. However, we do not expect subject matter experts (SMEs) to become familiar with CommonKADS in order to populate task specifications. Rather, we envisage that knowledge engineers (or developers with knowledge of CommonKADS) would take transcribed SME knowledge or doctrinal task breakdowns and derive specifications from these. Specifications could then be used to generate tasks in a range of target languages, although only Soar is described here.

2.2 Introduction to CommonKADS

In the early days of Expert System analysis and design, it was common for programmers to bury knowledge components of the system within the implemented model, making it difficult to reuse, understand and maintain. Improvements were made by using modular design approaches, which involved structuring system knowledge into a knowledge level specification prior to design and implementation [6]. The knowledge level "provides a means to describe problem solving behaviour independent of how it is realised at the representation level" [7]. A number of standard methodologies for knowledge level modelling include the Generic Tasks approach [17, 18], the Components of Expertise [19], the Knowledge-Based System Analysis and Design Support (KADS) methodology [20, 21] and CommonKADS [5]. CommonKADS attempts to unify the best features of the others. In CommonKADS a series of interrelated models of the knowledge-base or agent system are built according to the three phases listed below:

• The system context analysis phase: In the initial phase, the context of the planned system (i.e. the need for the system, proposed sphere of operation and potential influence upon the current organisation) is defined using a series of data tables. These tables define the so-called task, agent, and organisational models. For CGF development, these models have limited significance and are not described further although see [8] for more details.
• The knowledge analysis phase: This phase involves deriving the implementation language independent specification of the system or task. This requires building the so-called knowledge model and communication model of the system. The knowledge model specifies the CGF task(s), is a central feature of CommonKADS, and thus is the primary subject of review in this paper. The communication model describes the communication behaviour of the task with respect to other interdependent components (e.g. other CGF agents tasks). The derivation of the communication model is also important for CGF development, but due to space limitations is not described further although see [8] for more details.
• The design phase: This is the final phase of modelling which leads to the definition of the system design. Each system design is specific to the target implementation language required. Although we have produced Soar models from CommonKADS knowledge model specifications directly by hand, the automation of CGF code generation from these specifications would probably require formulating an intermediate representation (the equivalent to a design model) for each target CGF language version derived.

 

2.3 The CommonKADS Knowledge Model

The knowledge model represents the knowledge level specification of a task and comprises three main knowledge components:

• Domain Knowledge: This describes knowledge of the domain specific to the CGF agent task. This knowledge includes domain concepts (or domain classes to use object-oriented terminology) and rules that define how domain concepts are manipulated by the task. These rules are collected into rule-sets which themselves are collected into one or more knowledge-bases.
• Inference Knowledge: This describes how domain concepts are used to carry out the specified task. Inferences are atomic problem-solving components of the main task. An inference is a ‘black box’; defined only by stating its input and output domain knowledge, and the rule-sets used to manipulate these inputs. Note that some authors suggest that the processing structure or ‘body’ of inferences might be defined as axioms in First Order Logic [22]. In addition to inferences, a specialised construct called the transfer function is used to define communications between the specified task and the local environment. A breakdown map of the specified task showing the flow of domain knowledge though the task, its component inferences, transfer functions and any associated rule-sets is called an ‘inference diagram.’
• Task Knowledge: This describes the goals of the task and the sub-activities that must be carried out to achieve it. Task knowledge is described in a hierarchical fashion: where the task itself is decomposed into smaller tasks. At the lowest level of decomposition, tasks are linked to inferences and transfer functions.

These components are explained in more detail in the following sections. Examples given in forthcoming sections are based upon the ‘defend ship planning task,’ an Anti-Aircraft Warfare Officer (AAWO) task that defines the generation of a countermeasure defence plan in response to an airborne attack upon a frigate. This example is used throughout this paper.

2.3.1 Domain Knowledge

Domain knowledge of the specified task consists of two components: a domain schema (or schemas) and one or more knowledge-bases, made up of sets of rules of a given rule type. The domain schema resembles an object oriented class hierarchy, describing domain concepts, their attributes, permitted values, and their class generalisations relevant to the specified task. For the AAWO defend ship planning task, the domain schema might include objects such as aircraft and missile types, radars, hard-kill and soft-kill ship defence systems, allied and friendly forces etc.

Rule-types provide the templates for rule instances – the latter being vital components as they encapsulate the bulk of the semantic knowledge of the task. Rule-types describe generalised relationships between domain concept attributes. Rule-types are made up of a rule antecedent and consequent with their cardinalities, and the so-called ‘connection symbol,’ which represents a semantic description of the rule’s implication operator as shown in Figure 1.

RULE-TYPE Counteraction-Plans-To-Consider

ANTECEDENT: Aerial-Target-Distance-Information

CARDINALITY: 1 .. N

CONSEQUENT: Countermeasure-Plans

CARDINALITY: 1 .. N

CONNECTION-SYMBOL: Consider-Action

END RULE-TYPE Counteraction-Plans-To-Consider

Figure 1. Example rule type from the planning task

A rule instance is derived from a rule type. Each knowledge model task specification may contain tens or even hundreds of rules of many different rule types. Collections of rule instances that have a similar function (perhaps they are all used in problem solving by one particular inference, for example), are combined into a rule-set as shown in Figure 2. Note that the object ‘Tg’ shown in Figure 2 represents the aircraft or missile threat to the ship. Groups of rule sets such as this are then combined to make up the knowledge base of the specified task.

RULE-SET Counteraction-plans USES Consider-Action FROM Counteraction-Plans-To-Consider

Distance-from-ship(Tg) > 0 AND Distance-from-ship(Tg) <= 250 AND Class-type(Tg) = Aircraft-Target CONSIDER-ACTION Cm-ship-speed(Tg) = Full;

Distance-from-ship(Tg) > 0 AND Distance-from-ship(Tg) <= 250 AND Class-type(Tg) = Aircraft-Target CONSIDER-ACTION Cm-support(Tg) = Fighter-patrol;

Distance-from-ship(Tg) > 100 AND Distance-from-ship(Tg) <= 250 CONSIDER-ACTION Cm-manoeuvre(Tg) = Turn-to-minimum-radar-reflectance;

END RULE-SET Counteraction-plans;

Figure 2. Part of a rule-set taken from the planning task

2.3.2 Inference Knowledge

Domain knowledge (object classes and rule-sets) is abstracted into ‘knowledge roles’ for use in inference definitions. There are two types of knowledge role – dynamic and static. Dynamic knowledge roles are altered during problem solving (changed by the inference during its operation) and thus tend to represent inference input and output domain items. The definition of the generic target ‘Tg’ knowledge role taken from the planning task is shown in Figure 3.

KNOWLEDGE ROLE Tg

TYPE: dynamic

DOMAIN-MAPPING: target

END KNOWLEDGE ROLE: Tg

Figure 3. Dynamic knowledge role example

Static knowledge roles cannot be altered, but are required by the inference to guide problem solving. Rule-sets are therefore represented as static knowledge roles. Figure 4 shows how the plan-composition static knowledge role is defined as an instance of the Counteraction-plans rule-set shown in Figure 2.

KNOWLEDGE ROLE plan-composition

TYPE: static

DOMAIN-MAPPING: Counteraction-plans

END KNOWLEDGE ROLE: plan-composition

Figure 4. Static knowledge role example

Inference definitions themselves are based upon knowledge roles such as these. For example, the AAWO defend ship planning task incorporates a ‘generate’ inference (Figures 5 and 6). This inference is used to select defence activities (i.e. rules) applicable to defending the ship from the current threat; selecting these from the plan-composition knowledge role, and prioritising these activities according to the rules contained within the preferences rule-set. Depending on the target base class type (aircraft or missile) and the target distance from the ship, combinations of rules are be selected to devise a preliminary plan for defending the ship. The generate inference is shown in Figure 5.

INFERENCE generate

ROLES:

INPUT: Tg

OUTPUT: possible-plans

STATIC: plan-composition, preferences

SPECIFICATION: Select and process rules from plan-composition and preferences applicable to target data

END INFERENCE generate

Figure 5. The generate inference

2.3.3 Task Knowledge

In CommonKADS, the hierarchical decomposition of task knowledge is represented diagrammatically using schematic maps called inference diagrams that show the sub-tasks, inferences and transfer function components of the task. When designing an inference diagram for a task, it is usual to base this upon a generic task template selected from the CommonKADS template library [5]. Each generic task template describes the inference structure required to solve a generic class of problem, e.g. a diagnosis task, a planning task, a monitoring task.

The AAWO defend ship planning task inference diagram is shown in Figure 6. This inference structure is a simplified version of the CommonKADS planning task template, and contains the following knowledge components;

• Dynamic knowledge-roles: These are items of domain knowledge (variables or objects with associated attributes and values) that are passed into the task and are manipulated by the task.
• Static knowledge-roles: These are the rule-sets used by each inference during problem solving.
• Inferences: The atomic problem-solving components of the task.

Figure 6. The AAWO defend ship planning task inference structure

The knowledge inputs of the defend ship planning task include the target object (with its radar type, distance from ship, class type attributes) and the Rule of Engagement (ROE) data. The planning task draws up a list of prioritised defence plans (the output of the task) to protect the ship against the target in accordance with the ROE specified (hence these input parameters are shown as the goal of the task).

As described in section 2.3.2, the generate inference produces a prioritised list of possible defence activities against the target according to rules given in the plan composition and preferences rule-sets.

The hard requirements knowledge role is a list of any other targets for which defence plans already exist. The select-subset inference accepts both the new target with its potential plan data and all other targets as input parameters. Using rules specified in the constraints rule-set, the inference reorganises all of the plans for each target into a new plan list while removing any conflicting ones. The preference values of each plan are then reorganised according to target criteria specified in the preference ordering rule-set.

To complete the CommonKADS knowledge model, the task specification itself – composed of two parts, the task declaration and the task method - is derived from the inference diagram. The task declaration provides a general definition of the task in terms of its goal, and input and output knowledge roles. The task method implements the task declaration, listing dynamic knowledge roles internal to the task (e.g. possible plans) and the inferences used by the task, including the control structure of these inferences (i.e. pseudo-code that defines the way in which these inferences are scheduled). Note that static knowledge roles (rule sets) are not listed in the task method – these are located in the inference definitions. The task declaration and task method pair elicited for the AAWO planning task is given in Figure 7.

TASK planning

GOAL: Devise a plan to satisfy the target and ROE input requirements

ROLES

INPUT: goal

OUTPUT: preferred plans

END TASK planning;

TASK METHOD defend ship planning task

REALISES: planning

DECOMPOSTION:

INFERENCES: generate, select subset

ROLES:

INTERMEDIATE: possible plans, hard requirements

CONTROL STRUCTURE:

generate ( goal -> possible plans);

select subset ( possible plans + hard

requirements -> preferred plans);

END TASK METHOD defend ship planning task

Figure 7. Example task declaration and task method from AAWO planning task

2.4 CommonKADS and CGF modelling

The applicability of CommonKADS to CGF task specification and modelling is suggested in [23] (p. 15). An extensive review of the pros and cons of CommonKADS modelling for CGF use is given by Allsopp [8]. To summarise, the CommonKADS approach does offer the following advantages for CGF development:

• CommonKADS can be used to produce CGF task specifications that are reusable.
• CommonKADS is expressive enough so that when specified tasks are implemented, they produce doctrinal behaviours in CGF agents.
• CommonKADS is a standard methodology for knowledge-based system analysis and design. Is well documented and tools exist for structuring knowledge into CommonKADS specifications.

CommonKADS also has a number of potential limitations for use in CGF modelling. It is not a cognitive modelling methodology per se and therefore the resultant models do not contain behavioural moderators, team-working behaviours, and may not be realistic outside their field of use. These limitations are discussed further in section 5.

2.5 Soar

The Soar architecture is built upon a theory of cognition [2]. It is based on a production-like rule based system with an inference engine and a learning capability. Its architecture can be described using Newell’s ‘physical symbol system hypothesis’ [24], in which a physical symbol system is described as being composed of memory, symbols, operations and interpretations upon these symbol structures in memory. In Soar, symbols exist in memory as tokens that represent elements within expressions such as words in a sentence, numbers or letters [24]. Operations are processes that manipulate input symbol structures and produce other symbol structures for output. Interpretations are processes that execute operations on the basis of input symbol structures. These elements are combined in Soar to form a very general, universal computational system.

Soar has been used for CGF modelling for many years. The Tac-Air Soar pilot model proves Soar’s effectiveness at modelling complex human tasks [25]. Other examples of the use of Soar for CGF work include the modelling of planning and teamwork in rotary wing aircraft [26], pilot fatigue [27], group behaviour [28], US Special Forces [29], and The Battle Force Tactical Trainer [30].

3. Method

The methodology described here focuses on achieving the goals of the research described in section 2.1. This involved taking a small number of military tasks (though the AAWO planning task is the only task described in this paper), specifying them in CommonKADS, deriving CGF models from these tasks, and documenting this process.

3.1 Task Source Documentation

The main task used during our experiment was the AAWO defend ship planning task. Elements of this task have already been introduced earlier in this paper. The source documentation of this task was elicited from SME interviews at DERA by a team of psychologists including one of the authors [31]. This task was originally elicited so that an AAWO model could be derived from it for use in the UK STOW’97 demonstrator.

3.2 Deriving the CommonKADS Specification

The CommonKADS specification was produced from source documentation by the following steps:

• AAWO defence plan decisions taken according to various target types, distances from ship etc. were extracted from the source document. Thus, for example, the various weapon systems used for defending the ship, the applicable target distance ranges for each weapon system and any conflicts between the use of different systems was noted.
• Domain object class data was extracted from the scenario, which included the aircraft and missile types, their radars, flight heights and speeds, and the ship defence systems.
• The generic planning task template was selected from the CommonKADS task library for use as a basis for the defend ship planning task inference structure.
• Defence plan data previously extracted from the planning task document was then examined to see how it could be used to model components of the inference structure. Firstly, plan data was mapped to the types of dynamic knowledge roles described in the template. Then sets of rules were extracted from the plan data and used to model the static knowledge roles. An iterative process of analysis and specification led to the final task specification described in Figure 6.

3.3 Producing Soar code from CommonKADS

In the initial step, Soar productions needed to initialise the program state and to specify the goal of the task were coded. In addition, a number of productions had to be devised for identifying aircraft and missile radar types and for deciding whether these were friendly or enemy aircraft or missile contacts in order to decide whether to initiate defence planning. This identification activity was not part of the planning task specification itself, but was modelled in Soar so that test inputs might match those specified in the original AAWO scenario document.

Productions to model the generate inference, the plan-composition and preferences knowledge-roles were written next and completed before moving onto the select subset inference and its associated rules.

The generate inference and its rule-sets were modelled as a series of operator proposal and operator productions, all of which run within their own ‘generate’ problem space. In the plan-composition rule-set of the CommonKADS specification, the target range from the ship affects the nature of the defence systems selected by the AAWO to make up the preliminary defence plan. Therefore, it was convenient to devise operator proposal and implementation operators to cover individual sections of the overall target range from 0 Nautical miles (Nm) i.e. overhead, to maximum contact range (250 Nm). If a contact appeared at some distance between these extremes, the relevant operator for the given range fires to initiate the target defence plan including only those defence systems relevant to this distance. The defence system preference values (that indicate the order of use of the defence weapon systems) are also set at the same time. Thus preference ordering rule-set values are also incorporated within the generate operator productions.

The select subset inference and its associated rules were more difficult to implement because this inference is involved in comparing preliminary defence plans drawn up for the ‘new’ target with any previously defined defence plans of other ‘active’ targets already identified. Where plan conflicts arise, these must be resolved. The knowledge required to resolve these conflicts is specified in the constraints rule-set. The implementation of this inference involved segregating operators into groups, some of which were involved in resolving conflicts in missile target plans, others were concerned with conflicts in aircraft target plans, and still others were concerned with conflicts between hard-kill and soft-kill defence options. There was not always a one-to-one mapping between CommonKADS rules and Soar operators because, on some occasions, several rules were merged into a single operator for brevity.

3.4 Preliminary Attempts at automating Soar code generation

Although the automation of the complete CommonKADS task specification was not attempted, the automation of Soar code from preliminary domain schema representations was examined. In practice, an intermediate form of the Soar rules was generated to improve the ability to generalise in the future. Programs devised by the authors then used this intermediate form as an input to produce text files containing the proposal rules, application rules, and termination rules, which can be run directly by the Soar system.

4. Results

This section includes a description of the size of, and the time taken to develop the CommonKADS planning task specification and resultant Soar code derived from it. Results of preliminary attempts to generate Soar code automatically from parts of the task specification are also described.

4.1 The CommonKADS Specification

Important components of the CommonKADS planning task have already been introduced in Figures 1 – 7. Although these only represent a small part of the entire specification, it is hoped that they provide a general impression of the appearance of the CommonKADS knowledge model.

It is difficult to describe the size of the complete specification as the AAWO domain can contain many class objects and their super types (aircraft, missiles, radars, and their classifications), not all of which are needed in any one scenario. Table 1 shows the number of lines of specification of the task and inference definitions, and the number of rules contained in each rule set of the CommonKADS model.

Knowledge Model Element No. of lines/rules

Task + Task Method 8 + 19 (respectively)

Generate Inference 16

Plan Composition Rule-Set 18

Preferences Rule-Set 24

Select Subset Inference 16

Constraints Rule-Set 16

Preference Ordering Rule-Set 6

Main Domain Classes 4

Table 1. Sizes of certain components of the defend ship planning task knowledge model

The main domain classes shown in Table 1 include the objects: Rule of Engagement, Aircraft Target, Missile Target and the Aerial Target (this is the super-class of Aircraft Target and Missile Target). Many alternative domain classes and their super-types were also identified to provide the background domain knowledge that the AAWO would need to know to conduct related tasks, e.g. to identify a radar contact as a friend or a foe.

It is also difficult to quantify the amount of time spent devising the CommonKADS specification for the following reasons:

• Time was needed to become familiar with the CommonKADS methodology itself.
• Time was needed to become familiar with the task domain.

Given these limitations, the development of the CommonKADS specification took around two months. A subsequent task (of equivalent size) would probably take less time to specify now that the authors have experience of task modelling using CommonKADS.

4.2 Soar code generated from CommonKADS task

A Soar model was produced from the CommonKADS specification in a relatively short time (1 week) and the entire model consisted of 55 production rules. However, 11 of these rules were involved in classifying radar contacts as friend or foe prior to defence planning (see section 3.3), and these were not derived from the CommonKADS specification. In terms of operation, the model appeared to be accurate with respect to source documentation, producing output plans matching those expected from the documented AAWO scenario.

The generation of the Soar model was no doubt facilitated by familiarity with the AAWO task due to preliminary work on the CommonKADS specification. However, the Soar code produced was bulky. Production rules were often large, although this may reflect the nature of the domain and task. We do not claim that code derived in this manner is elegant, or efficient. However, it appears that Soar productions can be derived from CommonKADS specifications of military tasks such as the defend ship planning task.

4.3 Auto generation of Soar code from domain knowledge

Preliminary work on auto generation of Soar code from data contained in the domain schema of the CommonKADS model has shown that it is possible to successfully generate a large number of rules automatically. However, one major issue that must be given further consideration is when, where, and how to introduce elements into the Soar rules that are not represented in the knowledge level description of the task. These elements are peculiar to the Soar agent architecture that are needed to make the rules fire correctly.

5. Discussion and Conclusions

Military tasks specified in CommonKADS may be used to generate CGF code exhibits doctrinal behaviours. These specifications are reusable because they make no CGF language implementation commitments, but with a number of limitations:

Low-level CGF tasks that interface with simulation architecture specific objects, e.g. tasks that determine how a vehicle moves, accelerates, fires etc. can only be defined in CommonKADS using general axioms because implementation specific definitions cannot be stored at the knowledge level. These axioms need considerable further elaboration when implemented in CGF code, so that the CommonKADS specification alone will not be sufficient for defining every aspect of every military task that might be represented at the knowledge level.

CommonKADS rules are monotonic and do not handle uncertain conditions. The ability to handle uncertainty must be elicited from task documentation and coded separately if needed in the CGF model.

There is no representation of CGF collaborative team-working knowledge in CommonKADS, so that CGF models derived from CommonKADS specifications will have limited team working behaviour [32].

CommonKADS has limited cognitive modelling capability. Although it is suitable for modelling doctrinal tasks, psychologically plausible CGF agents cannot be derived from CommonKADS specifications alone, and must be augmented with additional cognitive components within the CGF model (e.g. behaviour moderators).

5.1 Task reuse

It is very likely that deriving a Soar model directly from source documentation will not take as long as producing an intermediate CommonKADS representation prior to Soar code. It is also likely that Soar code produced from CommonKADS specifications will be less efficient than code produced by an experienced Soar programmer from source documentation directly (Figure 8).

Figure 8. CommonKADS and task reusability

The gains in our approach however become apparent when versions of the same task are coded in more than one CGF language. At this point, it is likely that deriving a Soar and a JACK model (for example) from source doctrine will take longer than deriving a Soar and JACK model from a CommonKADS specification . If the CommonKADS specification is carefully documented and archived, there is no reason why it should not be used many times over.

5.2 Soar productions derived from CommonKADS

The Soar model produced from the CommonKADS specification appeared to be inelegant and inefficient, although not all Soar code generated from CommonKADS specifications will necessarily be inefficient. Specifications of tasks with low numbers of rules are likely to produce more efficient code.

Ideally, automation of code generation from specifications would be desirable. But the automatic or semi-automatic generation of Soar code from CommonKADS tasks presents a number of challenges listed below. These problems must be addressed before complete rule sets can be generated that will implement a complete cognitive agent in a Synthetic Forces environment:

• The inference structure of the CommonKADS task specification affects the nature of the Soar code derived from it. Some optimisation of inference structure for use with Soar, as was carried out for the defend ship planning task, may be necessary. It would be difficult to automate this.
• There is no direct mapping between CommonKADS rules and Soar operator and operator proposal productions. Sometimes an operator proposal and operator pair may be used to encode the knowledge contained in several CommonKADS rules. Sometimes an operator proposal and operator pair may be used to encode the knowledge contained within a single CommonKADS rule. This inconsistency presents problems for automation.
• Using our current prototyped approach for Soar code generation, the directory structure, which mirrors the Soar operator hierarchy, is lost during code generation, i.e. a flat-file of Soar rules is produced. This directory structure is useful for interpreting and debugging complex Soar systems, such as Tac-Air Soar.
• As mentioned in section 4.3, there is the problem of how to include information peculiar to the Soar agent architecture that is not included in the knowledge level specification but is essential for the proper working of the CGF entity encoded in Soar.

5.3 CommonKADS and TAQL

In this paper, our foremost concern has not been to compare TAQL and CommonKADS, but rather to identify a representation that could be used to specify military tasks for generating CGF code in a range of languages. In this respect, CommonKADS may differ from TAQL, for CommonKADS specifications are language independent, though Newell et al [2] claim that problem-space representations (in TAQL or any other language) should be capable of specifying problem solving behaviours in languages other than Soar.

We cannot directly compare Soar development times using TAQL and CommonKADS as we have not modelled identical tasks using both of these. It is very likely that our approach will take longer although ultimately it offers the possibility of CGF code generation in a range of languages.

The fact that Soar code may be generated from CommonKADS specifications suggests that, at least for doctrinal knowledge, problem spaces and tasks might be roughly equivalent structures. Whether CommonKADS specifications can be used with TAQL to produce Soar code has yet to be investigated.

5.4 Future Directions

The research described in this paper should be viewed as a preliminary ‘proof of principle.’ The applicability of CommonKADS to military task modelling needs further investigation. Although a few military tasks have been specified already, a wider range of military tasks need to be specified.

If it is proven that CommonKADS can be used to model a wide range of military tasks, it is necessary to pursue this research with a trial to derive empirical data to define, for example military task complexity versus CommonKADS specification size and implementation times, lines of CommonKADS specification code versus lines of CGF code generated etc. Research is also needed to investigate ways of generating CGF code in a range of languages from these specifications.

5.5 Summary

It would be useful to have a high level CGF language that compiles into a cognitive architecture such as Soar. We have used CommonKADS for this purpose and conclude that it shows promise given that it worked for a small number of test cases as part of the large RCAB system. We believe that CommonKADS specifications can also be used to produce JACK code, and potentially, ACT-R.

6. Acknowledgements

Thanks to Dr. Frank Ritter for his helpful advice and comments for improving the early drafts of this paper.