Geospatial Data Updating at Sea

A growing problem exists with forward-deployed electronic chart display and information systems (ECDIS) in obtaining and updating geospatial data(electronic nautical charts). This problem is commonly referred to as distributing geospatial data over the “last tactical mile”. As a solution to this problem, the US Navy has developed software called “Network Centric Mapping Database (NCMD)”. NCMD is a software capability that automates data distribution, with a focus on geospatial data (vector map data, raster map data or imagery). NCMD has been developed as a web service and multi-tiered software application that allows deployed C4ISR system to autonomously obtain and update geospatial data. This article describes NCMD software architecture and operation, and discusses how NCMD will be used in the US Navy and the potential commercial applicability of NCMD technology.

The concept of Network Centric Mapping Database (NCMD) was initially proposed as a solution to the existing updating process for Digital Nautical Chart (DNC) used by electronic chart display and information systems (ECDIS) in the US Navy fleet. The current updating process, known as Vector Database Update (VDU), is cumbersome and time-consuming. While formulating technical ideas for NCMD, we concluded the design could support systems far beyond ECDIS. Any Command, Control, Computer, Communication, Intelligence, Surveillance and Reconnaissance (C4ISR) system connected to a Transmission Control Protocol/Internet Protocol (TCP/IP)-based network would be able to use the NCMD software to obtain and update geospatial data as needed, autonomously, without the need for operator intervention. The NCMD software development has beenaccomplished by the Space and Naval Warfare Systems Center (SPAWAR), located at Naval Amphibious Base, Little Creek, Norfolk (VA, USA) and in collaboration with the UK Hydrographic Office (UKHO), Taunton (UK). This work was endorsed by and has been developed with the co-operation of the Office of Global Navigation at the National Geospatial-Intelligence Agency (NGA), in Bethesda (MD, USA).

NCMD Software Description
The NCMD software consists of four main components. On the server (network infrastructure) side, there are the installer, database, and web service software components. On the client side (deployed C4ISR system), there are several options, ranging from an embedded capability to a standalone Windows-based application. It is not necessary for the C4ISR system to support a web browser; NCMD is designed to be a machine-to-machine interface. Figure 1 presents a physical and logical topology for the NCMD software.

In Figure 1, across the top you see the physical realisation of the NCMD software. On the left, specific geospatial data products are installed (for example, DNC, ENC) by an operator using the NCMD installer software. This manages the geospatial data installation process into the NCMD MySQL database. This database would be located on appropriate regional or local servers of the desired network. The database is front-ended by the NCMD web service software. The web service is the only part of the NCMD server software that can be accessed by the client (the source data is protected from corruption from the client). This geospatial data is then pulled as eXtensible Markup Language (XML)-encoded messages through the network by a client, located on the right side of the diagram. This client can be any system or device that supports a TCP/IP connection. This same data flow is represented in a logical fashion on the bottom of Figure 1. The design of the NCMD software is scalable and virtual; all the server components do not have to reside on the same physical server. The NCMD software can rapidly scale to accommodate a highly dynamic number of users. The NCMD software uses a Service-Oriented Architecture (SOA) in that the application and infrastructure are implemented as shared re-usable resources. The architecture is presented in Figure 2.

Alternative Architectures Investigated
In addition to the architecture described above, we also looked at various methods of data distribution using off-the-shelf software systems and components. Commercial file replication products and Peer-To-Peer (P2P) systems were considered.

Commercial file replication products were deemed unsuitable for a variety of reasons, including that they:
-are platform- or operating-system specific
-do not handle synchronisation of access to relational datasets
-do not support spatial constraints
-are generally not suitable for use on low-bandwidth, high-latency network connections, where we expect NCMD to initially exist.

P2P systems were ruled out for many of the same reasons, as well as security concerns. A truly network-centric force using the Global Information Grid (GIG) will, however, most likely support some P2P operation between trusted sources.

NCMD Web Service Component
The web service component is the heart of the NCMD software. Web services allow applications to exchange data over the network in the form of XML messages. Web services allow integration of disparate systems: cross-platform, cross-programming languages, server independent, and operating-system independent. Viewed from an n-tier application architecture perspective, the web service is a ‘veneer’ for programmatic access to a service that is then implemented by other kinds of middle–ware. Access consists of service-agnostic request handling (a listener) and a façade (interface) that exposes the capabilities supported by the business logic. For NCMD, the business logic is the database logic that supports geospatial data (vector or raster). The service is self-describing; all of the data types used for input/output are described in the Web Services Description Language (WSDL). In the near future, NCMD will support binary delta compression to minimise message size pulled by the forward deployed client.

Advantages of a web service include that it:
-provides a simplified mechanism to connect applications regardless of technology or location
-is based on industry standard proto–cols with universal support
-leverages standard transport mechanisms
-supports multiple connectivity and information-sharing scenarios
-is loosely coupled
-is self-describing and supports automated discovery.

Challenges for a web service include:
-inefficient use of network bandwidth
-can be overcome via compression prior to installation
-network latency
-can be overcome via asynchronous transactions; however, this increases the client-side code complexity.

NCMD Installer Component
The purpose of the NCMD installer is to create and maintain the NCMD database schema, to create product types, which will be distributed by NCMD, and to install and update product instances.

Another function of the installer is to create new product types. The NCMD design supports automated client-side discovery and support of new user-defined product types. This allows NCMD to support distribution of product types that do not currently exist, or to support usage models that currently have not been defined (for example, software patches in the form of executable files).

NCMD Database Component
The database is implemented with MySQL 5. The advantages of this approach are:
-open source/cross platform
-scalable
-administration tool
-query browser tool.

The database is used by the installer component and the web service component. The database makes use of a C++ connector library, which provides optimised database driver connectivity between C++ applications and the MySQL server.

The NCMD database implements and supports product metadata using an abbreviated Federal Geographic Data Committee Standard – FGDC-STD-001-1998. The standard defines 10 different information classes and three types of data entry: mandatory, mandatory if applicable, and optional. Current plans are to work with the UKHO to migrate the data catalogue towards the ISO 19115 standard for the next generation of metadata. Future geospatial data products from the NGA and most national sources will use the ISO 19115 metadata standard.

NCMD Sample Client Component
NCMD provides a sample client primarily implemented in Java (Java Two Standard Editions, J2SE). The rationale for using Java for the client implementation is due to Java’s support for most common hardware/operating system platforms and its provision of standard libraries that provide support for XML, input/output, etc. The client component interfaces through the network with the web service component of the NCMD software. This is the vital link behind the NCMD operation. The client periodically checks with the server to see if any new product types, or new instances of a given product type, are available that satisfy the client’s constraints. The design supports constraint of retrieved product instances by product type (for example, DNC, Tactical Ocean Data [TOD], ENC), temporal constraints (for example, all instances from time t to time t+n), spatial constraints (for example, a bounding box defining latitude/longitude coordinate pairs), or other fields as described in the server-side FGDC metadata held within the database component).

NCMD – How Does it Work?
Here is a simplified description of the process for NCMD software operation. On the server side, an operator populates the NCMD MySQL database using the NCMD installer software. The NCMD database would then be a collection of geospatial data products like DNC, TOD, ENC, Additional Military Layers (AML), imagery, etc. After product installation, the NCMD web service publishes to an online catalogue. In the future, NCMD would register into the Universal Description, Discovery and Integration (UDDI) registry across the Navy Enterprise network (GIG).

Now on the client side, the client is connected to an available network. This could be a fixed shore-based network, forward deployed afloat network, or a mobile ad hoc network on the edge. An operator then configures the NCMD client software to determine the geospatial data products needed to meet mission requirements. The NCMD client discovers and subscribes to the online catalogue. Then, the client ‘pulls’ required geospatial data from the NCMD database via the NCMD web service. The client autonomously updates the required geospatial data products to meet mission requirements as updates become available on the server side (machine-to-machine interface).
Data integrity is achieved using the inherent TCP mechanism. TCP is responsible for verifying the correct delivery of data from client to server. TCP provides support to detect errors or lost data and to trigger retransmission until the data is correctly and completely received.

Next Steps
These are the next steps for the NCMD project:
-continued joint testing between SPAWAR and the UKHO
-improve the installer software automatic metadata extraction algorithm
-continue to refine the sample client to increase performance and to adapt to existing network latency and bandwidth (for example, bandwidth throttling)
-begin integration of NCMD client software with US Navy programs.

Commercial Applicability
The design of NCMD is certainly not limited to working on naval military networks. In fact, the development and testing of NCMD has occurred on the internet via a virtual private network between SPAWAR and the UKHO.. Commercial ECDIS customers could establish a network interface and configure the NCMD client to maintain any geospatial data products they required. Consideration will have to be given in the web service software to licensing requirements. In a typical scenario, a customer would order the desired charts online and then NCMD would download them automatically, and maintain them current for the time period that was purchased (for example, a 1-year licensing agreement). In addition, NCMD could also help with distribution of ECDIS software patches, including automatic installation and completion reporting to the user.

Long-term Solution
The long-term solution to the geospatial data distribution and updating problem is most likely the use of Open Geospatial Consortium (OGC)-compliant rendering solutions using Geographic Markup Language (GML). This type of solution would require a constant high-speed connection and significant software development. Existing C4ISR systems are not yet capable of supporting an approach using rendering solutions and GML; however, this holds much promise for the future.

Conclusion
NCMD has been demonstrated to provide a unique approach to obtaining and updating geospatial data for deployed C4ISR systems. NCMD is built around a machine-to-machine interface in order to allow the warfighter to fully exploit the network-centric environment. Other programs that are developing similar capabilities are either relying on an operator using a browser (an intelligence analyst for example), or are developing a restricted design providing one product to one system. NCMD can rise above all of these designs to allow a common solution to the DoD problem of obtaining and distributing geospatial data autonomously. NCMD can be a single solution to delivering all current and future geospatial data over the ‘last tactical mile’. At a recent demonstration at the UK Ministry of Defence, NCMD was described as “the art of the possible”.