Large scale knowledge based systems for airborne decision support

Large scale knowledge based systems for airborne decision support

H. Howellsa,* , A. Daviesa, B. Macauleyb, R. Zancanatoc

aSystems Integration Department, Air Systems Sector, Defence Evaluation & Research Agency, Farnborough, UKbDirectorate of Future Systems (Air) 2, MOD (PE), Bristol, UK

cCambridge Consultants Limited, Cambridge, UK

Received 1 December 1998; accepted 17 March 1999

Abstract

At ES 96 during the Keynote address, the point was forcefully made that software houses have contributed little to the advancement ofKBS. In the defence area, especially that of aerospace systems, extensive use has been made of the expertise of software and system houses indeveloping validation methodologies (VORTEX), real time (MUSE) and multi-agent (D-MUSE) software and together with Universities, aknowledge acquisition toolkit (PC PACK). In the UK at DERA Farnborough within the Airborne Decision Support Group, Air Sector, thesesoftware and tools have been developed and applied to problems in building Decision Support Systems for Maritime Air applications. Thedemanding aircrew tasks are characterised by the need for assimilation and interpretation of multi-sensor data to devise tactical responses inreal time based on prevailing tactical doctrine and aircrew experience. The applications include Decision Support for Anti-SubmarineWarfare (ASW), Anti-Surface Warfare (ASuW), Airborne Early Warning (AEW) together with ASW/ASuW and the proposed AEWtechnology demonstrators. Currently the transition is being made from the laboratory concept demonstrators to large scale technologydemonstrator programmes as a risk reduction exercise prior to specification for airborne use. The proposed AEW TDP includes extensivemodularity to support extensibility and component reuse.q 1999 Elsevier Science B.V. All rights reserved.

Keywords:Knowledge based systems; Technology demonstrator; Architectural design

1. Introduction

1.1. KBS group background

The Knowledge Based Systems Group within SystemsIntegration Department at the Defence Evaluation andResearch Agency (DERA) in Farnborough have beenengaged for more than a decade in research and applicationsof knowledge based decision support [1]. The initialimpetus was the general search for a means of managingaircrew workload. Mission systems were being specified forairborne use where manufacturers’ claims for improvementin mission performance were high but without correspond-ing assessment of the role of the aircrew required to attainsuch performance levels. From earlier work by the coreteam members on less sophisticated airborne systems theindications were that the newer proposed mission systemswould generate a wake of different, additional attentionaldemands. The emergent technology of expert systems wasthen considered as a potentially useful avenue to explore.

1.2. Shells and limitations

The then new LISP based Expert Systems shells such asInference Art and Intelicorps KEE, together with lesserknown proprietary products were acquired and experiencegained in diagnostic level problems such as replicatingaircraft warning panels. Experience in devising and usingstructured interview techniques in problem identificationand assessing performance in Human Factors studieswhere more reliable measures were not available enabledthe team to build skeletal laboratory demonstrators whencoupled with the commercially available shells. Whilst theearly experiences with the shells indicated the potential ofthe approach in functionally representing the required sali-ent features in narrowly focused airborne domains the soft-ware speed limitations rapidly became apparent.

1.3. Application expansion

It was realised that the fundamental design of LISP posedan impediment to the real time demands of airborne appli-cations. To extend the laboratory demonstrators to capabil-ity which would interest military customers would requirefaster software and prototype build methods far beyond

Knowledge-Based Systems 12 (1999) 215–222

0950-7051/99/$ - see front matterq 1999 Elsevier Science B.V. All rights reserved.PII: S0950-7051(99)00012-X

* Corresponding author. Fax:1 44-1252-392720.E-mail address:[email protected] (H. Howells)

those commercially available. The group proposed thatmore systematic methods of knowledge acquisition, amore appropriate form of validation methodology wereneeded for Knowledge Based Systems (KBS) developmenttogether with a real time capability more in line withairborne requirements. This would require considerableresearch investment, but coincidentally, the United StatesGovernment General Accounting Office (GOA) reportpublished in 1981 drew attention to financial implicationsof continually assuming that the increasing significantelements that system designers were unable to specify incomplex military systems could be compensated for bythe ingenuity of human operators.

1.4. Realisation

Following the publication of the GAO report, a NATOWorking Group was set up and reported in 1984 that KBSshould be examined as one possible means of addressingsuch problems [2]. One of the authors was a member of theNATO Working Group and used the rationale for the needfor research funding that if expertise was needed to generatecomplex systems, if that expertise could be incorporated incomputer code within the mission systems as advice thenoverall mission performance ought to improve. Such argu-ments were successful and paved the way for the large scaleUK-MOD funded research programme covering KAmethods (PC PACK) [3] real time software (MUSE andD-MUSE) [4] and a validation methodology (VORTEX)[5] which currently are being applied to demonstrators forknowledge based decision support for Maritime Airapplications.

2. The first maritime air application—anti-submarinewarfare (ASW)

Previous background by the author in human factorsassessments of Maritime Air sensor and mission systemsled to an awareness that the task was characterised by adeveloping situation where fine judgements were examinedrather than the more deterministic reactions encountered instrike mission management. When an application wasneeded to evaluate the capability of the validation metho-dology research which recommended a spiral developmentlife cycle for rapid prototypes for KBS workstation demon-strators then the developing nature of the maritime missionwas seen as an appropriate application to demonstrate theconcept of KBS [6]. The skeletal Anti-Submarine Warfare(ASW) scenario used proved doubly effective in demon-strating the tools designed for validating the knowledgebase and when combined with the measures of effectivenessdefined by the maritime customer illustrated that the tacticaladvice offered exceeded the customer expectation of thelaboratory demonstrator [7]. The Validation of Real TimeExpert Systems (VORTEX) application had been written inLISP due to the group’s experience with LISP based shells.

At that stage it would have been difficult to make the casefor funding a separate line of software development due tothe large scale US-DARPA investment in LISP during theinitial phase of the Pilots Associate Programme [8].However, the Group’s experience in sponsoring the devel-opment of the real time software development toolkit(MUSE) and its successful application in a laboratorydemonstration of a multi-engine helicopter warning paneland its performance on tapes provided by NASA Ames ontelemetered systems status data from the X29 researchaircraft provided sufficient evidence in its potential to secureadditional funding. The next expanded version of the ASWapplication that focused on producing a decision supportsystem for controlling more than one platform usedMUSE rather than LISP.

3. The second maritime air application—anti-surfacewarfare (ASuW)

At the same time that the group was developing the LISPfunded ASW demonstrator for the validation methodologyevaluation, parallel effort was also being expended in apply-ing MUSE to a skeletal mission manager workstationdemonstrator using a fixed wing strike scenario [9].Compared with earlier success of using MUSE with diag-nostic applications with multi-engine helicopter warningpanel and the NASA X29 data the different data types andvarying input frequencies began to reveal limitation in thereal time performance of the MUSE software. Additionalresearch funding was then received to develop a multi-agentreal time capability (D-MUSE) to maintain the softwareperformance against the more demanding scenarios envi-saged. Maritime air experience during the Gulf War hadrevealed the difficulties in tracking high speed fast patrolboats which would also camouflage their presence by moor-ing alongside oil rigs or inserting themselves in slowmoving fishing fleets. This application was consideredideal to assess the real time capabilities of the multi-agentsoftware and so a knowledge based Anti-Surface Warfare(ASuW) decision support system workstation demonstratorwas built [10].

4. Aircrew roles in ASW/ASuW aircraft

Maritime aircraft are required to operate world-wide,often at short notice and in a variety of roles. To fulfilsuch demanding requirements the aircraft carry very sophis-ticated sensors and complex systems which are configuredand managed by the aircrew to most effectively meet theneeds of the varied missions. Such variation in operatingenvironments and improved capabilities of future missionsystems led to the increasingly demanding role for aircrew.This role is characterised by:

1. A need to adequately consider the most appropriate mode

H. Howells et al. / Knowledge-Based Systems 12 (1999) 215–222216

in which to operate a sensor due to the increased numberof modes.

2. The need to handle a vastly increased volume of dataprovided by improvements in sensor performance. Thisis generated by the increased number of targets likely tobe seen over longer ranges. The lower signal to noiseratios at which detection is possible also increases thenumber of false contacts.

3. Greater uncertainties being generated regarding trackidentity, position, course and speed due to the difficultiesin classifying and localising targets at longer ranges.

4. Data from different sensors needs therefore to becombined in order to improve the confidence in trackidentity, position, course and speed. This requirementis needed to use sensors co-operatively, dynamicallyreviewing the combination, create a significant challengeto aircrew.

5. Reduction in contact time for sensors results from conti-nuing improvement in threat performance so that thewindow of opportunity for aircrew to detect, recogniseand react to new contacts is diminishing.

The increasingly demanding role imposed on the aircrewand the associated time criticality associated with the neces-sary decision making based on assimilation, integration andinterpretation of data from a multi-sensor mission systemtherefore lends itself to a knowledge based decision supportsolution.

For the Anti-Submarine Role (ASW), the aircrew tasks(UK Observer, US Tacco) which could be addressed byapplying KBS technology would be:

1. Deployment of Active Dipping Sonar and sonobuoyscreening barriers;

2. Active and passive location;3. Attack and re-attack;4. Lost contact procedures; and5. Management of assets.

Similarly in the Anti-Surface Warfare role (ASuW) theaircrew tasks would be:

1. Classification of surface sensor data;2. Generation of surface picture based on classification;3. Path predicted for associated tracks;4. Plan area search routes;5. Assign contacts; and6. Route production for confirmation of identity and hosti-

lity level of tracks.

5. The ASW/ASuW technology demonstratorprogramme (TDP)

5.1. Background and rationale

Other departments within DERA, particularly those asso-ciated with airborne and submarine surface sonars and anti-

air warfare in surface ships had also been examining andapplying expert system technology. The Maritime AirCustomer decided that a Technology DemonstratorProgramme or US/ATD be mounted as a risk reductionexercise before considering the exploitation of KnowledgeBased Decision Support technology in a mission system forthe next generation of ASW/ASuW airborne platforms. Totest the need for such decision support and to establish thebreadth of functionality required structured interviews wereconducted with authoritative sources of future operationalrequirements for maritime airborne platforms, DERAresearch sites and contractors engaged in developing work-station demonstrators. A functionality matrix was usedincorporating a weighting schedule agreed by interviewparticipants to establish need for and the functionalitydemanded of a decision support system to manage work-load, maximise the use of mission systems and sensorresources to achieve consistency of mission performance.

5.2. Organisation and components

Having agreed on the need and functionality required forASW/ASuW decision support the many workstationdemonstrators developed under the sponsorship of DERAbut targeted at specific areas of functionality were assessedfor their relevance to the declared aim of satisfying theMaritime Air Customer requirement. A rainbow consortiumof contractors had been formed in order to manage theintellectual property rights aspects and exploit the specialistexperience of teams engaged in the wide range of small-scale laboratory demonstrators. Representative threatscenarios were provided by the maritime Air Customer.The Rainbow Consortium included contractors with experi-ence of building workstation demonstrators in the targetdomain, simulation environments to evaluate such demon-strators, data fusion systems and software to implement suchschemes. These building blocks under consideration for theTDP included seven separate workstation demonstrators,three simulation facilities, two computer simulation envir-onments, two real time software toolkits and a data fusionsystem. Evaluation of building blocks was conducted usinga selection strategy based on weighted requirements matrixincluding tasks defined in the approved scenarios togetherwith functionality requirements [11]. This assessmenthaving been achieved allowed the optimum architecture tobe defined together with the associated components. Exam-ination of maturity levels, flexibility and implementationconsiderations in association with a cost/benefit analysisled to the selection of the architecture and necessary compo-nents to achieve the core decision support system to imple-ment the desired level of complexity to influence theMaritime Air Customer of the potential of the technology.This rigorous evaluation and trade off study resulted in theselection of an architecture which included:

1. A computer simulation environment, hosted on

H. Howells et al. / Knowledge-Based Systems 12 (1999) 215–222 217

workstation which incorporated ASW and ASuWmodelling capability.

2. A data fusion/association capability based on AAWFrigate TDP and ASW mission system.

3. The ASW and ASuW decision support laboratory work-station demonstrators.

4. The real time, multi-agent software development toolkitD-MUSE due to its level of maturity; richer selection ofprogramming strategies; represented the core of the keybuilding blocks and cold be interfaced to the simulationenvironment.

5.3. Complexity

Further additional tasks are under discussion for inclusionby the contractors and the Maritime Air Customer in orderto increase the capability of the ASW/ASuW KnowledgeBased Decision Support Technical DemonstratorProgramme. Man-in-the-loop evaluations are planned inorder to demonstrate military worth of knowledge basedDSS for the Maritime Air Customer. It can be seen thatthe nature and complexity of the tasks are very differentfrom those usually encountered in the literature. A recentNATO KBS Working Group reported that KBS technologywas sufficiently mature for applications in aeronautics andspace due to their potential having been demonstrated inFrance, Germany and the USA in diagnostic and planningtasks in fielded systems [12]. More multi-function systemsincorporating complex architectures were reported as beingbetween the laboratory and fielded systems. The MaritimeAir TDP described in this paper represents such an interimsystem.

6. The third maritime air application—airborne earlywarning (AEW)

The MATDSS TDP represented a decade of research insoftware and tool development together with small scale,piecemeal Maritime Air applications developed by differentDERA departments and commercial organisations. Thestrategy for MATDSS was to use the building blockssystematically selected to create a TDP to demonstrate thepotential military worth of decision support within a missionsystem for consideration for inclusion in a Naval StaffRequirement. A somewhat different strategy is beingadopted for the Airborne Early Warning platform [AEW].The timescale available for developing the preliminaryworkstation demonstrator is 3 rather than 8 years with theintention to move directly into a TDP. The AEW domain issignificantly different from ASW/ASuW and possesses a farmore demanding real time requirement. This was to beaddressed by engaging the developers of the real timemulti-agent software and knowledge acquisition toolkittogether with a Royal Navy AEW Instructor with directaccess to AEW experts. The intention is therefore to build

a comprehensive DSS from scratch rather than attempting toexpand narrowly focused building blocks to attain acomprehensive decision support capability.

6.1. Overview of the AEW task

A snapshot of a typical AEW scenario, in which AEWhelicopters are responsible for protecting an advancingnaval task force would include:

1. the task force being protected;2. a frigate forward of the main force hosting the AEW

aircraft;3. a further frigate well advanced of the task force used as a

weapons platform against incoming threats;4. an AEW helicopter ahead of the task force searching for

contacts and controlling the AEW operation;5. fixed wing intercept aircraft well ahead of the force, in

combat air patrols (CAPs) defined by the AEW helicop-ter, awaiting intercept request from the AEW helicopter;

6. further frigates on the task force flank used for ASWtowed array operations (passive sonar); and

7. further helicopters ahead of the task force performingactive sonar dipping in ASW operations.

It is the task of the AEW helicopter to classify as early aspossible all hostile airborne contracts in the vicinity of thetask force, and to initiate the prosecution of those contacts itbelieves represents a threat to the task force, by efficientmanagement of available assets.

6.2. Objectives of the demonstrator

The purpose of this Decision Support System (DSS) is todevelop a system which can be used to assess the expectedincrease in operational effectiveness of the Airborne EarlyWarning (AEW) platform when operators are supported intheir task by intelligent decision aids. From a successfuldemonstration of capability and improved effectiveness ofoperators, is the potential of moving the application towarda full mission system.

It is important to note that the proposed decision aid is notintended as an autonomous system with which the AEWoperator has minimal interaction. Instead, it is required tobe a co-operative system in which the system and operatorare able to utilise the skills most appropriate to their capabil-ities. Even if it were technically feasible to provide anautonomous system, it is not obvious that this would be adesirable feature, since such a system would risk leavingAEW operators with no obvious control or responsibilityover the progress of the sortie.

6.3. AEW DSS scoping

The basis of the application scoping was the resultsobtained from many Knowledge Acquisition (KA) sessions.Each session focused on eliciting knowledge from an AEWexpert with many years of experience, and with knowledge


of the likely evolution of present day AEW incorporatingfuture technologies. During this phase a semi-structuredinterview technique was employed in order to provide thenecessary wide breadth of coverage of knowledge requiredfor the scoping exercise. All sessions were recorded andtranscribed (using the KA toolkit PCPACK, describedlater) providing a permanent record of the interviews,which will be available for reference throughout the devel-opment of the DSS.

The main roles for maritime forces in AEW were identi-fied as Surveillance, Attack Co-ordination, Airmanship(including self-defence and safety) and Communications.Tasks in support of these capabilities include radar andsensor handling, detection, situation assessment, tacticaldecision making, fighter control, reporting and airmanship.For each of these tasks different levels of support wereidentified, ranging from routine activities to those requiringactive intelligent processing. Eleven possible areas ofsupport for the AEW tasks were identified:

• Barrier Positioning;• CAP Control;• Radar Sensor handling;• Tactical Decision Making;• Prosecution and Attack Co-ordination;• Reporting and Data Link Management;• Database management;• Airmanship;• Self defence and Safety; and• Secondary Roles.

These provide the sub-division of the major functions likelyto be involved in performing AEW. For each of these areas,specific tasks were identified in which a DSS could provideoperator support.

7. Design methodology and KA tools

Although the initial scoping phase utilised semi-formalinterview techniques, the current design phase is employinga more formal approach using the KA toolkit (PCPACK).

7.1. KA Toolkit: PCPACK

Essential to the design process, significant benefits accruefrom using an appropriate toolkit in support of KA. For theAEW DSS knowledge acquisition is being supported by theKA toolkit PCPACK [3]. PCPACK consists of an extensivecollection of KA tools, KADS style directive models, andfacilities for supporting project management and documen-tation. These include:

• GDM Workbench;• Protocol Editor (or Transcript Analysis tool);• Hyperpic tool;• Laddering tool;• Matrix tool;

• Card Sort tool;• Repertory Grid tool;• Case Editor and Rule Induction tool;• Rule Editor;• Project Management; and• Project Documentation.

The KA toolkit binds the various tools together using anobject database, within which the instances of conceptsderived by each tool, and their inter-relationships, arestored. The integrated database allows the different facetsof the stored knowledge to be viewed and manipulated byother tools in the toolkit.

7.2. The generalised directive model (GDM)

An important part of the design process using PCPACK isthe identification of the Generalised Directive Models(GDMs), for the tasks of the application.

The GDM comprises a statement of the inference stepsperformed during problem solving (for example, abstract,match and refine), the classes of domain descriptionsserving different problem solving roles (PSR) within themodel (for example observables, variables, abstract solu-tions and specific solutions) together with the dependenciesbetween the two.

These inference steps and roles correspond to partitions inthe knowledge of the system. Aiding acquisition and theorganisation or indexing of the knowledge required for thesystem to function.

For example, a directive model for performing situationassessment could be to match the known features of a parti-cular contact (track) with typical descriptions of certaintypes of objects (schemata).

7.3. Detailed KA for AEW

All of the KA carried out during the detailed design phasefor the AEW DSS is being captured using the PCPACKtoolkit, which will be used to provide a knowledge modelfor each of the tasks identified during the scoping phase.

The design process is often found to be iterative, since theGDM may be unknown until an initial examination of thetask has been carried out. Subsequently, an appropriateGDM may be identified but it is found that it does notcompletely match the task decomposition. In this case itmay be desirable to reassess the task to see if it can be recastto match the GDM more closely.

8. Implementation toolkit: D-Muse

The proposed implementation framework for the AEWDSS is D-Muse, a real time knowledge based toolkit for thedevelopment of distributed applications.

D-Muse provides facilities for running a collection ofnamed processes that are inter-connected by a network ofdeadlock free communication paths.


Each Muse process provides the following functionality:

• flexible knowledge representation;• support for modular code development;• support for real time operation;• extensible;• distributed object management; and• session management.

D-Muse is not restricted to inter-connecting Museprocesses, but can also be used to communicate with otherprocesses, such as graphical user interfaces and simulationfacilities.

9. Architectural design

Another important goal for the AEW DSS is that it shouldprovide an extensible implementation that supports, wherepossible, the reuse of components, and the ability to growthe system without having to re-engineer components. Toachieve this, an agent based architecture has been chosen,which is being implemented within D-Muse.

The internal architecture for the agent is being designedso that they can be populated directly from the knowledgemodels created during the design phase.

Analysis of the task decomposition and its GDM willidentify the requirements and capabilities of the agent. Inparticular, elements of the world model will be defined bythe input and output parameters to the GDM. Requirementsand capabilities will be broadcast (handled by afacilitator

agent) to the other agents of the system. The other agents areable to respond with offers of appropriate information, orwith requests to utilise the capabilities offered by the agent.

For example, the identification of Missile EngagementZones (MEZs), important for safe route planning, cancome from many different sources, some of which maynot be implemented in the initial DSS. The addition offurther agents that expand the scope of MEZ identificationis facilitated by the autonomy offered in an agent architec-ture. The initial application architecture is shown in Fig. 1.

In Fig. 1 the agents on the right represent the kernelfunctionality of the system, the central set of agents definethe support agents that interface with, in our DSS, a simu-lator and a workstation based operator interface. Thisdecomposition is not definitive. Changes are already beingconsidered to partition a number of the agents into smalleragents, with more specific responsibilities, which thenreport to a controlling managing agents.

10. Agent communication language

The agent communication language chosen for the AEWDSS is the Knowledge Query and Manipulation Language(KQML). KQML is a language independent message formatand message-handling protocol designed to support run-time knowledge sharing among agents.

For Muse implemented agents (this will apply to most ofthe agents within the DSS), only the semantics of KQMLwill be implemented.


Fig. 1. Key software components.

However, where there is a need to communicate withagents that have not implemented in the Muse language,or do not support D-Muse streamed object communication,the full syntactic form of KQML messages will beemployed.

This approach will aid future desires to integrate the DSSwith legacy system, such as intelligence and emitter data-bases.

10.1. Optimisation of inter-agent communication

An agent defines a logical partition of functionality withinthe application, but does not require that it be localised to asingle processor. A proposal is currently being investigatedof ways of distributing agent functionality across processorboundaries to find ways of improving efficiency of inter-agent communication in a distributed environment.

In terms of its implementation it is envisaged that this willinvolve sharing elements of the world and acquaintancemodels across processor boundaries (implemented usingD-Muse mirrored objects).

10.2. Fault tolerance and agent mobility

Since the proposed D-Muse agents can be created dyna-mically across any of the available CPUs, the run-timesystem provides capability for implementing a limiteddegree of fault tolerance within the DSS. For example, if aprocessor dies it is possible to terminate the function of lowpriority tasks, and use the freed resources to host newinstances of agents from the lost processor.

11. Current status of the AEW DSS

The methodology, design tools and the proposed agentarchitecture for the AEW DSS provides the developers withconfidence in the development of the application.

In particular, the close relationship between the method-ology, the realisation in the PCPACK toolkit and the abilityto map the knowledge concepts directly onto features of theimplementation language, provide a means of estimating thesize of the application (including the size and quantity ofdata structures, and the complexity of the various functionalareas and tasks of the application).

The utilisation of an agent architecture, althoughgrounded more in practical implementation rather than atheoretical implementation, provides the developers withmeans of reusing software components and supportingfuture modular expansion.

The use of KQML style communication between agentsof the application, allowing easily transition into the KQMLsyntax for communication with external data sources thatwill grow in importance as the system expands.

12. Conclusions

In a recent journal article, Hayes-Roth, drawing on twodecades of research experience for DARPA, contended thatmuch has been achieved using AI techniques in an incre-mental fashion in relatively small-scale exercises [13].However, he contended that the effort needed to be concen-trated over a period of time in specific domains to demon-strate potential before adapting and transferring solutions tonew situations. Context adaptable building blocks, re-useable knowledge and composite architectures for multi-task systems were recommended as necessary constituentsof a future strategy for AI. The contention of the authors’ ofthis paper would be that in concentrating on Maritime AirASW [14], ASuW [15], AEW [16] for almost a decade, andin developing the necessary support software tools andmethodologies, together with the re-use aspects, the KBSGroup within Air Sector, DERA in the UK already conformto most aspects of the Hayes-Roth paradigm.

The paper describes two contrasting approaches for thebuilding of TDPs. Each possesses its own merits and as bothhave yet to be completed, the relative merits of differentapproaches have yet to be demonstrated and assessed.Both represent a complexity far beyond that referred to inthe recent US survey reported in AI Magazine [13] andthose cited in the NATO/AGARD report [12]. They alsoexhibit the very different characteristics which differentiatebetween military and commercial applications as repre-sented by the combination of demanding requirements anddomain complexity as identified in the recent EUCLID RTP6.3 report [17]. MATDSS encapsulates a slowly developingscenario whilst AEW demands a much faster tempo ofresponse. The real time software and knowledge acquisitiontoolkits used are commercially available products. Both areattempts to demonstrate the military benefit of incorporatingdecision support in airborne mission systems.

A recent US survey indicated that the KBS tool andconsultancy market within North America was $258 millionbut reported that the activity in the UK remains conservativein development and deployment of expert systems. Mari-time Air is certainly an exception to this generalisation butawareness is no doubt limited due to exposure being usuallyconfined to military forums.

Contrary to the point made in the Keynote address at ES96, UK software and system houses are deeply involved indeveloping software, tools and building applications tosatisfy the demanding requirements of Air Sector DERAin Knowledge Based Decision Support as represented by adecade of research and culminating in two large scaleprogrammes described in this paper.

References

[1] H. Howells, R. Bickerton, Decision making in ASW helicopters usingKBS advisors, RAeS Conference Role of Intelligent Systems inDefence at St Hugh’s, Oxford, March 1995.


[2] S. Merriman (Ed.), Applications of system ergonomics to weaponsystem development, NATO-DRG Panel 8 Workshop, RMCS Shri-venham, 1984, unpublished.

[3] N. Shadbolt et al., PCPACK Release Notes, Version R 1.0, October1995.

[4] S. Martin, H. Howells, Real Time Software for Knowledge Basedsystems, IEEE Colloquium, London, 1995.

[5] M. Grisoni, H. Howells, European Workshop on Verification andValidation of KBS, Proceedings of EUROVAV 91, Jesus College,Cambridge, July 1991.

[6] M. Grisoni, Vortex Final Report, Logica CAM.706.70015-FRC,September 1986.

[7] H. Howells, C.G. Peden, Tactical decision aid for ASW aircraft, DRAReport, January 1992, unpublished.

[8] R. Small, The pilot’s associate—today and tomorrow, Proceedings ofthe First USAF EAORD International Workshop on Human–Electro-nic Crew, Ingolstadt, September 1988.

[9] E. Doe et al., Applied study into KBS for fixed wing aircraft, FARLReport 262/224, March 1987.

[10] R. Zancanato, H. Howells, An agent based helicopter decision supportsystem, British Computer Society Expert Systems ConferenceProceedings, Cambridge, December 1995.

[11] P. Bentley et al., Need and functionality of a maritime aircraft, TDSSLogic Report, February 1996.

[12] H. Winter (Ed.), Knowledge based guidance and control functions,NATO AGARD-AR-325, 1995.

[13] F. Hayes-Roth, what works and what doesn’t, AI Magazine 18 (2)(1997) 000.

[14] R. Ellis, A report on the design of tactical decision aids for maritimeaircraft operating in a multi-platform co-operative environment, DRAReport, November 1996, unpublished.

[15] A.J. Davies, H. Howells, KBS mission manager concept report,DERA Report, May 1997, unpublished.

[16] H. Howells, A.J. Davies, Recommendations for the application ofKBS decision support technology for the FOAEW platform, DERAReport, November 1996, unpublished.

[17] Euclid, Knowledge engineering for advanced information processing,EUCLID RTP 6.3, 1997.


Documents

Large scale knowledge based systems for airborne decision support