Volume 1, Number 2, July 1998
The Implementation of GIS in Defence Systems
Abstract
Emerging defence systems need to be able to exploit terrain in the form of digital geographic information. The component of defence systems that will perform this critical role is the geographic information system (GIS). The implementation of GIS poses many challenges for system developers and this paper aims to expose some of the most important issues that must be addressed. Three issues are raised as typifying the complexities of GIS. The need for compromise between speed, functionality and openness in a GIS implementation is identified. The need for, and complexities of, geographic data management are discussed and finally the need for organisational change is proposed. The paper concludes by briefly examining the reasons why some defence systems continue to be planned without GIS services despite all the arguments that this is not a sensible approach.
Introduction
Terrain matters to the military commander. It supports almost all decisions whether administrative, operational, tactical or logistical. At present, most armed forces continue to use the paper map as the principle tool for understanding terrain. As computer systems become a more important decision support tool, they too will need to exploit digital geographic information (DGI). The component that exploits DGI is a geographic information system (GIS).
There is an illusion that many countries have deployed battlefield command, control and communication information (C3I) systems. This is simply not the case. The few nations that have deployed systems are generally using dated computer technology with very limited spatial (GIS) capabilities. The only nation that has a fully deployed, spatially enabled C3I System is Sweden, but more of that later. So no nation need feel that it lags behind in this digitisation process. There are many, many words and very few practical examples.
There are many reasons for this probably the most significant of which is that IT has only just become mature enough to establish a realistic battlefield infrastructure. For the first time it is now truly realistic to buy systems ‘off the shelf’ and deploy them to warfighters. Now that IT has got to that stage many nations are faced with the realities of building C3I systems for the first time. All of a sudden the practical issues concerned with the implementation of GIS services as part of these systems must be addressed.
This paper aims to define some of the issues that must be considered if GIS implementation is to proceed as affordably as possible. It cannot raise all the issues that must be considered but the aim is to help defence IT players appreciate that GIS deserves consideration as a critically important element of an IT implementation.
Components and compromises
Most military commanders will recognise that a tank is a careful balance between firepower, protection and manoeuvrability. No commander would approach a tank designer and demand a tank that travels at 120km/hr, having a gun with a 10,000m range and protection against all known weapons. Because the technology of the tank is mature, its design is covered in military science syllabi around the world. There is therefore a widespread understanding of the need for compromise to achieve well-balanced performance.
Sadly, the same understanding is not there for computer technology generally and GIS specifically. Even well educated commanders will demand the very best speed AND functionality AND openness of a GIS without accepting that compromise is essential. At this early stage in the deployment of the computer into the warfighting environment the level of understanding is limited.
GIS is particularly difficult in this respect because of the large number of issues that have to be balanced. Just thinking in terms of the traditional breakdown of components in a GIS (hardware, software, applications, data, personnel and organisational issues) it becomes clear that in a military procurement, each of these aspects is controlled by different organisations. Hardware and core software will often be in the domain of infrastructure projects whilst applications are developed by separate projects. Data is provided by separate military geographic organisations that themselves need to compromise between the needs of different services, systems and organisations. Personnel have enormous training burdens that again compromise between different needs. And finally, conservative military organisations have their own resistance to change and existing doctrine, that is in turn an optimum (that is, a compromise) way of achieving mission requirements.
A recipe for success here is to accept GIS as a critically important element of defence systems and identify an agency that becomes responsible for GIS implementation throughout defence. Although the resource for this will be new and therefore attract hostile scrutiny, each defence IT project will face reduced risks as its GIS issues are centrally and expertly addressed. Typically it will be the national defence mapping agency that possesses the expertise that will be needed to establish and run this GIS centre.
The establishing of a GIS Centre was a critical factor in the overwhelming success of the Swedish Armed Forces in providing a strong GIS solution for the whole defence community.
Who will manage the geographic data? decision support from the real world
If DGI is used in a system it must be managed. The management functions include:
- getting data from the producer to the user,
- getting data into the system,
- getting data into the correct spatial framework, and
- maintaining the data.
Geospatial data supply infrastructure
A supply infrastructure must be in place to get DGI from the producing agency into the end-user system. An infrastructure for paper map distribution will exist but whether that can be amended to support the distribution of digital geographic information will need to be determined. Changing the system to cope with CD-ROMs will still need to be resourced. It should be noted that paper maps will continue to be needed and so this is an enhancement, not a replacement!
There is frequently discussion about the need to distribute DGI using high-bandwidth communications systems. Whilst there is little doubt that the availability of these systems will make distribution easier, the reality is that imagery and video teleconferencing are often seen as higher-priority. In any event, the bandwidth of a motorcycle courier with a pannier full of CD-ROMs is surprisingly high!
Getting geospatial data into the end-user system
Getting geospatial data into an end-user system involves two issues: where the data will be stored, and the format that it will be stored in.
DGI is typically produced in specialised map production agencies. This production is hugely expensive and so the burden is shared between many nations. This relies on a strong international standard for the exchange of DGI. The NATO Digital Geographic Information Working Group (DGIWG) has established and mandates the Digital Geographic Exchange Standard (DIGEST) to enable the exchange of DGI between producing nations and to the end-user.
It is increasingly recognised that whilst all end-user systems must be able to use DIGEST data, frequently these systems have requirements that cannot readily be met using the exchange-oriented (as opposed to exploitation-oriented) DIGEST data structures. Thus there is discussion about the need for a presentation standard for DGI, which will need conversion from the DIGEST standards. This conversion function will typically have to be accomplished as part of the process of getting data into the system.
DGI is voluminous. A typical theatre of operations might be covered by up to 40GBytes of DGI without high-resolution imagery or anything up to 1TByte with full high-resolution imagery cover. Even if the management function is only to be perceived as shuffling CD-ROMs in and out of a workstation, then there is a major issue to be confronted. The C3I System must be a tool that allows a user to do their work faster and better than could be done manually. If using that tool involves finding a single CD-ROM out of a 1m stack of CD-ROMs then by definition it isn’t a tool. So data needs to get into the system without imposing a burden on the operator. This implies either pre-loaded data (how many workstations have a 40GByte hard drive?) or data held on a central server (which can impose serious burdens on the network bandwidth). As will all the issues surrounding GIS implementations, the system developer must make careful compromises.
The correct spatial framework
If DGI is not placed into the correct real-world framework then people and things will be put into the wrong places. Underpinning the spatial framework is the complex and highly specialised science of geodesy. Whilst agreement on a standard spatial framework for all military operations has settled on the Universal Transverse Mercator projection based on the World Geodetic System 1984 spheroid and datum, the reality is that most countries maintain their own spatial framework.
Thus a system that can readily be demonstrated on a well mapped training area with data adhering to the UTM WGS84 standards can have very real problems when deployed to a country that still uses different spatial frameworks. Whilst mapping agencies will argue that they will maintain control of this, experience in several recent peace keeping operations indicates that commanders will receive data from a surprisingly wide range of sources.
The specialist nature of this element of DGI management further supports the argument for a dedicated geographic data server. This approach has been taken with the UK Army’s TACISYS system that provides deployed headquarters with a geographic data server, which is manned by geographic specialists from UK Military Survey.
Maintaining data
DGI is a representation of the real world. Typically in a warfighting environment that real world is suffering changes brought about by the course of the battle. Developers will need to evaluate how rapidly change needs to be reflected. There is no simple answer but it does help to identify the time-criticality of different types of change. Similarly, systems and processes will be needed to reflect these real-world changes in the command and control system? The maintenance process will involve many complex and specialist factors, which cannot be ignored during operations.
This latter point is critically important. It is possible to demonstrate an amazing wealth of functionality that appears not to need DGI management when the system integrator is demonstrating a system on the corner of a familiar training area. What will happen when the system is deployed to an unforeseen part of the world on an operation that may span a huge geographic extent? This issue must not be ignored: it will return to haunt the system user!
This need to maintain the spatial database adds weight to the argument for a specialist geographic data server.
The denial of the need for digital geographic data management
Despite the arguments above there are some that look at existing command and control systems and say, “these manage without DGI management… so therefore the future systems will as well!” They are ignoring two factors:
- Firstly, data management needs increase as the level of detail increases. Most existing systems are strategic systems that use very small-scale data. At 1:1,000,000 scale, significant real-world change has to occur before it is reflected on the map; this happens infrequently. At 1:50,000 a new road, bridge or forest changes may need to be reflected; this happens frequently.
- Secondly, most experience has been gained from airforce and naval systems where there is very little interaction between forces and terrain. New systems that are joint in nature or land-focused will have to handle the very complex interactions between Land Forces and terrain. This shift from DGI as wallpaper to DGI as a decision support tool is what demands proper DGI management.
It is recommended that every headquarters have geographic specialists who will be able to look after the background DGI. Some nations already have terrain teams or geographic support staff who can readily adapt to this new challenge (given time, specialist systems, money and training!). Many nations are going to need to examine where this resource is going to be found from.
Organisational challenges
The very conservative military organisations accept change reluctantly and generally change will only occur after the introduction of new systems, not in advance. This is set to cause problems with the introduction of IT since automating manual processes is not the best way to bring about success: reengineering of the fundamental processes is required.
The introduction of IT onto the battlefield represents as big a revolution in warfare as the introduction of gunpowder, the machine gun, the tank and aircraft. The key difference is that each of those technologies developed to meet direct military goals. IT is being introduced on the basis of much less clearly defined concepts such as ‘information warfare’, ‘situational awareness’, and ‘digitisation’.
IT will demand significant organisational change and much of that will focus on the critical role of the map in defence organisations.
Rather than explore the theoretical issues, let’s examine some real issues that must be addressed.
Map board or computer screen?
Decision support in today’s headquarters will involve staff gathered around a map board. It is around the map board that peer review occurs, mistakes get spotted and consensus achieved. As IT is introduced, the headquarters becomes screen-centric with the danger that staff will become reliant on this form of independent decision support.
Take the relationship between the map board and the computer view of the current situation – and there will have to be a relationship because surely no one suggests that the computer can replace the map board?
- Which will be the definitive view? The map board or the computer screen?
- Who will transfer information from the map board to the screen and vice-versa?
- Who will take voice situation reports (SITREPs) and transfer the information to the computer?
- Who will take data SITREPs and transfer the information to the map board?
- How will peer review in the decision support process occur?
These are all critically important questions and yet they are typically not being addressed. The reason is that these don’t become issues until the technology is introduced - the problem being that appropriate technology will be difficult to introduce until the issues are identified and resolved.
Garbage in, gospel out
Manual decision support exposes the user to all inputs and processes. Thus the user is aware of input limitations and process weaknesses. This is not so with a computer, which typically shields the user from the complexities of input and process: the very advantages of IT. To compound this problem the computer will generate a very good-looking output regardless of the quality of the input.
The concept of Garbage In, Gospel Out is not new to computer scientists but it is very new to battlefield users. As a headquarters becomes more reliant on computer-based decision support it will place a different emphasis on the ‘Observe’ and ‘Orientate’ components of the ‘Observe - Orientate - Decide - Action’ cycle. This in turn will demand subtle changes in organisation, as reconnaissance confirmation of analyses becomes more necessary.
Peer review
The flow of information around the map board in a headquarters is essential to the organisation. The group decision support environment allows the free exchange of information between different staff cells and also provides a forum for peer review. This allows mistakes and misunderstandings to be spotted before problems are caused.
As decision support migrates to the computer screen, how will this peer review (and indeed the whole group decision support process) occur? The organisation will need to evolve to ensure that peer review of decision support processes occurs.
Ignorance, idealism and vested interests
Despite the arguments above, the uptake of GIS remains slow. All too many defence systems continue to be planned without any definition for GIS services.
Three main problems are standing in the way of successful implementation:
- Ignorance: “We don’t need a GIS to put a map on the screen”.
- Idealism: “We’ll build a government GIS that’ll be free to all projects”.
- Vested Interests: “As a system integrator we’ll get most money by re-inventing the GIS bit”.
No GIS
Defence organisations remain ignorant of GIS in many countries around the world. Many people still fail to understand the difference between a picture of a map displayed on a computer screen and the functionality that a GIS provides. Education is the key to overcoming this problem: hence this paper.
‘ideal’ GIS
Five years ago, few commercial vendors had products that were relevant to the needs of deployable defence IT systems. At the same time, some nations, notably the USA, began to catalogue defence GIS requirements. The gap between commercial capabilities and defence needs provoked government bodies to start developing their own GIS solutions. At the time, their work was impressive and absolutely necessary.
Now the situation has changed. Commercial GIS vendors have completely closed the requirements gap whilst government developers lag behind. This recognition is slow to occur as the government contractors continue to spend large sums of money to try to keep up with the commercial world. The large sums that have been poured into these efforts lead some to argue that the investment must not be wasted and that further money should be spent to get these government GIS deployed.
As with all IT components, the commercial GIS world will win by continuing to lead in innovation, price, supportability and developability.
System integrators
Many system integrators are now appreciating the significant advantages of embedding commercial GIS within their C3I systems. Some have failed to recognise the advances in GIS technology that have occurred over the last five years. Others believe that they will maximise their revenues by avoiding paying licensing costs and developing their own GIS.
Many defence IT projects in their first iteration may place few demands on a GIS and thus tempt a system integrator to write their own very limited GIS solution. The problem will occur as the system evolves because adding functionality to these limited GIS solutions will be bespoke, costly and risky. Commercial GIS on the other hand will allow functionality to be added very readily and possibly by a different system integrator.
The way ahead
All of the issues raised above and the many, many more that are beyond the scope of this paper can be resolved - they are not obstacles to the implementation of successful defence systems, rather pointers to success.
There are systems emerging around the world where project teams, system integrators and GIS vendors have worked together to successfully meet user requirements. Most of these success stories are based on a sound understanding of the implementation issues raised in this paper.