The GRACE Consortium

Recommendations

The project has developed about 800,000 lines of new C++ code, 14 different C³I tools and a powerful integration architecture. These have been developed over 5 years using 125 man years of effort at a cost overall of around 16 MECU to the participating MoDs and 5 MECU to the participating companies. It is therefore important that all participating MoDs and companies achieve a high level of exploitation of the software and techniques developed. A programme re-using just 10% of the RTP 6.1 software - 1 or 2 tools and 80,000 lines of code - will potentially save 10 man years effort.

There are two main elements of the work that can be exploited - the architecture (CABLE/FIONA) and the tools. Taking individual tools is relatively easy, since in most cases the novel techniques are embodied in C++ code that is independent of the RTP 6.1 architecture. Exploiting the multi-agent architecture is a bigger commitment, which may be difficult in existing operational systems, but which provides major advantages in terms of ease of integration and of distribution over a heterogeneous architecture supporting multiple users, which are pre-requisites for next generation systems.

It is expected that the main route for exploitation will be into applied research programmes and technology demonstrators within national military research programmes. These need to adapt the RTP 6.1 work to particular national military applications, systems and architectures. In particular the tools developed by RTP 6.1 need to be extended by using more military input to develop deeper classified knowledge and constraint bases, and to be evaluated using a wider range of scenarios addressing particular national interests. It should be noted that RTP 6.1’s tools are example applications of AI techniques and in many cases the same techniques could be generalised to different scenarios and domains (army, navy, air, joint, non-military).

To assist exploitation of the results of the project:

• the RTP 6.1 demonstrator will be available for demonstrations at Logica’s Cambridge, UK office to June 2000

• a CD of project documents and software is available to participating companies and MoDs from Logica

• this World Wide Web site available with unrestricted access

• an FTP site (with password protection) is available to participating companies and MoDs for downloading software and documents.

RTP 6.1 has demonstrated what can be achieved today by integrating COTS software, and applying existing and adapted AI techniques to C³I. Two general recommendations emerge:

• for each problem tackled, a suitable AI technique must be selected, even though this means the final system may have to use a spectrum of different techniques working together

• architectures and standards adopted, even for research demonstrators, need to enable software to:

  • be distributed over a heterogeneous network of computers

  • support multiple co-operating users

  • incorporate a range of COTS software

  • use a wide range of AI or algorithmic techniques

  • integrate software from a number of different developers and legacy systems

  • be robust to new hardware and software innovations (eg a change of operating system and hardware platform), and

  • provide scalability so there can be a continuous transition from research demonstrators to operational systems.

Turning to specific recommendations for research building on RTP 6.1:

• For CABLE, the architecture needs to embrace DCOM and COM in order to be adopted more readily in operational systems running on PC NT. Questions about the security of CORBA and the performance overhead of CABLE and CORBA need to be answered. CABLE agents need to incorporate more innate intelligence (eg the Beliefs, Desires and Intentions model) in order to better support inter-agent negotiation. Java needs to be further assessed as an option for agent implementation.

• For FIONA, the user interface needs to better reflect the multi-agent nature of the underlying software, for example by enabling the user to see and start available agents, to monitor their activities and to more flexibly invoke agent services. The proliferation of dialogue boxes for agents needs to be controlled, for example by supplying a set of tabbed dialogue boxes for agents, analogous to the DOHP mechanism for geographic information. All aspects of the user interface (specific tools as well as the generic mechanisms) would benefit from greater military input.

• Regarding map facilities, rather than adding new functionality to the RTP 6.1 map and GIS facilities (MADRID, TED), it is recommended that commercially available libraries be incorporated into the architecture, coupled with the FIONA DOHP. It is noted that while Digital Terrain Elevation maps and scanned maps are relatively easily available, vector map data is only available for a few locations, and some is of poor quality. It is recommended that scanned maps be provided for user backdrop, terrain elevation maps for automated tools but that effort on tools that are reliant on good vector map data should be in proportion to the quality of available data. Roads then water are the highest priority vector features to make available to automated tools.

• For databases, data models and object models, it is clear that available standards and data are not keeping pace with the needs of research projects or operational systems. The GRACE Common Model (loosely based on the ATCCIS model) has met the needs of RTP 6.1 in both the army and naval domain.It is recommended that appropriate emerging standards be adopted and extended in new work (eg for the British Army, DCADM which provides both a data model and a populated encyclopedic database). However it should be noted that it is possible to translate between different data or object models provided a consistent underlying ontology has been used, so establishing the ontology is the key task.

• It is clear that ORACLE is the relational database of choice in operational systems and should be incorporated in future work, alongside an Object-Oriented Database such as ObjectStore. The RTP 6.1 architecture may need to be extended to take account of data distribution by database replication, rather than just through agent-to-agent service provision.

• A significant proportion of C³I tools are time-critical in the sense that the user needs the result within a particular time and is prepared to trade off solution quality against timeliness. Providing this is particular difficult in a multi-process and/or distributed environment, when the amount of CPU time available to any one process is not predictable, and the workload can vary depending on the scenario. RTP 6.1 has developed different solutions to this problem:

  • RTCE (Real-Time CABLE Enhancements) provide Solaris-specific mechanisms to guaranteeing and optimizing CPU resources given to an agent so that it can commit to providing a solution in a fixed time.

  • Some of the AI techniques (for example in TeART and RACAS) have been implemented in a form that lets them be interrupted at any time to provide the best solutions available up to that time.

These techniques should be consolidated and carried forward into future work.

• For situation assessment, the concepts used in TTA (Tactical Threat Analyser) for representing a current situation should be combined with those used in WAPC (Wide Area Picture Compiler) and ADVERTISER (user-defined alerts) to give an integrated set of tools for representing the current situation, assessing the threat, and alerting the user.

• The RTP 6.1 Plan Viewer display represents a key display format for military plans. Future work on this and other aspects of the user interface would benefit from more military evaluation. It would be beneficial to use a consistent internal representation of the plan (and its various elements), including constraints, throughout the tools developed and across the different domains (army, navy,...), for example in the form of a plan description language, consistent with those developed in other research programmes.

• The work has demonstrated the close relationship between military planning and simulation. Future work should further exploit the commonality between the tools used for each, and the possibility to use simulation tools to project future expectations as a basis for alerting the user to unexpected events.

It is clear that the trend is to greater international co-operation, in military operations, in procurement and in research. The hard-won experience of how to co-operate effectively on a large scale research project such as this, which is recorded in the management overview should be noted.

Produced by: Peter Martin / Russell Gordon / Mike Pockney Updated: 29 March 1999 Copyright Logica 1999