NewsAmphibious Assault Direction System AN/KSQ-1

Document Control No. PLI-CONOPS-1
Concept of Operations
for the
Position Location Information
of the
Coherent Tactical Picture
Version 1.0
Prepared by:
Inter-National Research Institute, Inc.
for the
Naval Sea Systems Command (PMS 317)
May 30, 1997

This document describes a Concept of Operations (CONOPS) for developing, maintaining, and disseminating the Position Location Information (PLI) component of the shared Coherent Tactical Picture (CTP). This is consistent within the framework of the CTP Integrated Process Team (IPT) established by DASN (C4I/EW/Space) for the purpose of establishing and disseminating a CTP among Navy and Marine Corps units.

The structure of this document provides the CONOPS in five sections. Section 1, Introduction, contains the purpose, background, scope, and objectives of this document. Section 2, Concept of Operations, contains the PLI CTP architecture overview, general policy and planning, organizational roles and responsibilities, information and track management, filtering and correlation responsibilities, and figures depicting a notional PLI data flow and PLI Component generation responsibilities. Section 3, PLI Architecture contains the DII COE, communications, processing, and display requirements. Section 4, Infrastructure Requirements, contains the minimum hardware, software, and communications requirements needed to process and disseminate the PLI component of the CTP. Section 5, Conclusions / Recommendations contains an approach for processing and timely dissemination of the PLI component. It is not meant to imply that this is the only feasible approach. However, these recommendations are in concert with both the architecture on the current platforms and the future DII COE approach for achieving a Common Operational Picture, of which, the CTP is a natural subset.

This is an early issue of the Concept of Operations for the PLI CTP. To help in understanding the concepts provided in this document, future issues will contain a hypothetical scenario with an operational sequence. In addition, this CONOPS is viewed as a first step in the natural progression or evolution to a Joint PLI CONOPS describing the PLI component of the Common Operational Picture (COP).

The Common Operational Picture, as defined in CJCSI 3151.01, dated 1 April 1997, is the integrated capability to receive, correlate, and display a Common Tactical Picture (CmTP); including planning applications, and theater generated overlays/projections (i.e., battleplans, force position projections, etc.). Overlays and projections may include location of friendly, hostile, and neutral units, assets, and reference points. The COP may include information relevant to the tactical and strategic level of command.

The CmTP, in this context, refers to the current depiction of the battlespace for a single operation within a CINC's AOR, including current, anticipated, or projected and planned disposition of hostile, neutral, and friendly forces as they pertain to US and multi-national operations ranging from peacetime through crisis and war. The CmTP includes force location, real-time and non-real time sensor information, and amplifying information such as METOC, SORTS, and JOPES

1.0 Introduction
1.1 Purpose
1.2 Background
2.1 PLI CTP Architecture Overview
2.2 Planning / Policy
2.3 Organizational Roles and Responsibilities
2.3.1 Commander, Joint Task Force
2.3.2 Air Component Commander
2.3.3 Ground Component Commander
2.3.4 Maritime Component Commander
2.3.5 Allied Participation
2.3.6 Other Agencies
2.4 Information Management Responsibilities
2.5 Track Management Responsibilities
2.6 Filtering Responsibilities
2.7 Correlation Responsibilities
3.1 Defense Information Infrastructure Common Operating Environment
3.2 Communications
3.2.1 Available Interfaces
3.2.2 Commonality
3.2.3 Expandability / Scalability
3.2.4 Independence
3.2.5 Common Message Structure (Future)
3.3 Processing
3.3.1 Injection
3.3.2 Correlation
3.3.3 Interoperability
3.3.4 Multi-Source / Multi-Sensor Correlation (Future)
3.4 Display
4.0 Infrastructure Requirements
4.1 Hardware
4.2 Software
4.3 Network


1.1 Purpose

The purpose of this document is to establish a CONOPS for the PLI component of the CTP during peacetime through crisis and war. In accordance with direction provided by the Naval Sea Systems Command (NAVSEA) Combat System Functional Allocation Board (CSFAB), this CONOPS is being drafted for the CSFAB PLI Systems Engineering Team (SET).

The CSFAB PLI SET directly supports the efforts of the Coherent Tactical Picture Integrated Process Team established by DASN (C4I/EW/Space) for the purpose of establishing and disseminating a Coherent Tactical Picture among Navy and Marine Corps units.

This CONOPS provides guidance on the establishment, dissemination, maintenance, and display of the integrated PLI component of the Coherent Tactical Picture. In addition, the CONOPS provides high-level guidance on organizational roles and responsibilities with respect to information and track management, filtering, and correlation.

(Back to the Table of Contents)

1.2 Background

The primary mission of the CSFAB PLI SET is to investigate the technologies and systems available to provide location and identification information from platforms (e.g., HMMWV's, LCAC's, etc.) and individuals within a theater of operations for Navy and Marine Corps C2 systems. The PLI SET examines the ways in which PLI is transmitted and processed to support the building, maintenance, and dissemination of a shared Coherent Tactical Picture.

During the course of this investigation, numerous systems have been identified (e.g., AN/KSQ-1, Applique, PLRS, EPLRS, SABER) as providers or potential future providers of PLI. These systems may be the actual sensor generating the PLI, a communications source for PLI, or a combination of the two. This PLI forms the basis for developing the ground tactical picture component of the CTP and provides significant contributions for the following: positive identification; coordination and deconfliction (e.g., required for close control of amphibious craft); Naval Surface Fire Support (NSFS); Ground Fire Support; Close Air Support; Combat Search and Rescue (CSAR); medical support; Theater Air Defense (TAD); and, sea-based logistics execution.

Since there is currently no common architecture, methodology, or overarching strategy for procuring and deploying PLI systems by the services, many problems have been identified which impede the ability to achieve an integrated CTP. The following subparagraphs delineate the major problems that this CONOPS hopes to minimize. To provide a total solution will require much more than a CONOPS. Section 5 presents recommendations to help solve these problems.

a. Data Latency. Current PLI producers have differing missions and thus are not always optimized for reporting PLI in a timely manner. The latency problem is exacerbated by many factors, including, but not limited to system performance, system design, and communications path availability for disseminating PLI. The delay in dissemination can severely degrade the usefulness of the information from both a mission support and situational awareness perspective.

b. Reporting Accuracy / Precision. Accuracy, in this context, is used to describe the confidence or certainty factor (e.g., associated Area of Uncertainty (AOU) for a contact report) that the object being reported is at the position being reported.

Current PLI sensor systems are known to have varying degrees of accuracy associated with positional reporting. These problems were documented during ASCID '96 when two sensor types were operated from one ground vehicle concurrently. This demonstration resulted in two separate and distinct tracks for one physical object.

Precision, as discussed here is used to denote the number of significant digits reported for a field (e.g., geo-position, course, speed). Current PLI sensor systems report with varying degrees of precision. As reports are transmitted and converted to the native formats of both the communications systems and destination systems, precision may be lost due to the inability of the receiving system to store, retain, and forward all significant digits. In addition, as the report is transmitted to a system capable of storing a higher degree of precision, a false measure of precision may be realized (i.e., adding more significant digits than were measured by the original reporting sensor).

c. Association / Correlation. For the purpose of this document, association and correlation are defined as follows. Association is the linking of two track objects in a hierarchical manner with the parent track inheriting common attributes and the position history of the child track in addition to its own. Correlation is the process of extending an existing track or creating a new track with an incoming contact report.

Many of the current systems use significantly different algorithms for the processes of association and correlation. The net result given perfect communications, identical filters, and input data (e.g., contact reports), is that these algorithms yield different depictions of the battlespace. Thus, the goal of a shared Coherent Tactical Picture is unachievable in the near-term.

d. Backward Compatibility / Interoperability. The above paragraphs highlight the current problems with differing message standards / formats and dissimilar processing algorithms (e.g., filtering, association, correlation, tracking). As systems are added to the PLI CTP architecture, limited interoperability can be achieved today. This directly affects an organizations ability to successfully prosecute it's mission. Many of the communications standards / protocols have changed without consideration for legacy systems currently in the fleet/field, yielding significant backward compatibility and interoperability problems that have yet to be addressed.

(Back to the Table of Contents)

1.3. Objectives

The first objective of this document is to begin to develop the basic techniques and guidelines necessary to build, maintain, and disseminate a CTP that contains information from multiple PLI sources, each having their own specific goals and requirements. To state that it is a beginning is important. Each of the areas discussed, from the various organizational structures to the many systems included in the architecture, are all rapidly evolving. It is envisioned that these basic guidelines will require tailoring for each organization, taking into consideration factors such as force structure, mission, AOR, and operational orders.

The second objective of this document is to provide a vision for the future. It describes a migration path to a common solution that leverages the investments made to date on currently deployed systems.

(Back to the Table of Contents)


2.1 PLI CTP Architecture Overview

The PLI CTP architecture begins with the sensors / sources and tactical forces gathering PLI and feeding it to their parent organizations at primary sites/nodes such as component commanders and the CJTF. Tactical Situation Directors at these nodes receive PLI through various communications links / networks and utilize both automated and manual capabilities to correlate and manage the PLI component of the CTP. Figure 2.1, PLI Data Flow (Notional), provides a notional depiction of this data flow from sensor to secondary sites / nodes, with associated view and timelines. Note that the timeline, depicting latency of the reported data, may be affected by many factors, such as: type of sensor system, communications path, performance of receiving nodes, and processing algorithms.

Once this raw PLI data is received at the primary sites / nodes designated as correlation and dissemination nodes, it is correlated with similar data from other sensors / sources to comprise the PLI component of the CTP. The PLI component is then correlated and fused with with information from supporting organizations inside and outside the AOR such as: component commanders, combined forces, national sensor community, tacintel, humint, sigint, and, Force Over-the-Horizon Track Coordinator (FOTC) to comprise the tactical track portion of the Coherent Tactical Picture. This process is further described in Paragraph 2.7, Correlation Responsibilities.

The CTP is then disseminated via tactical communications links / networks throughout the chain of command for the AOR. The Correlation and Dissemination Nodes (Primary Sites) and recipients will have the ability to control the information being transmitted and received via filters, described in Paragraph 2.6, Filtering Responsibilities. This capability allows all users, both primary and secondary sites / nodes, to tailor the presentation of the CTP to their specific display requirements in support of a mission, with the ability to revert back to the standard depiction of the CTP sent by the Correlation and Dissemination Nodes. In this architecture, in-theater resources transmit directly to the Primary Sites / Nodes for incorporation into the CTP, as well as directly to their existing tactical system architectures for the most timely dissemination to both tactical and command levels in a near-simultaneous manner.

(Back to the Table of Contents)

(Back to the Table of Contents)

2.2 Planning / Policy

In the future, this document and emerging detailed operating procedures and orders contained within OPLANS, CONPLANS, and OPORDERS should be standardized. This goal will ensure that more specific guidelines are available, tailored for each designated AOR.

To maintain C2 for each respective command echelon, each CJTF is responsible for maintaining the CTP for their AOR during peacetime through crisis operations and war. The CJTF will designate a single CTP Correlation and Dissemination Site (Primary Site) for the creation of the CTP. In addition, a backup site should be designated for robustness of reporting. Additional Correlation Sites may be designated as providers of distinct portions of the PLI Component of the CTP to the Primary Site. These additional sites may be assigned to process raw PLI data by geographic area, specific sensor type, source, or by Category and Identification type. It is important that there is no overlap of responsibility for reporting concurrently today. In addition to increasing the latency of the data, due to communications delays, many of the correlation algorithms in use currently are not robust enough to automatically process and integrate multiple reports for the same object.

(Back to the Table of Contents)

2.3 Organizational Roles and Responsibilities

The following paragraphs define the roles and responsibilities of a notional organization. It is intended that this section be tailored to meet the needs of a specific mission based upon force structure (e.g., task organization), AOR and the mission requirements.

(Back to the Table of Contents)

2.3.1 Commander, Joint Task Force

The Commander, Joint Task Force will designate overall management responsibility for the CTP (i.e., CTP Manager). This responsibility will include track management, correlation, filtering, and deconfliction of the CTP, as required. All or part of this responsibility may be delegated to the component commanders. It is essential that a backup organization / site be designated to maintain the robustness of the CTP during degraded mode operations (e.g., failure of primary responsible authority to prosecute the mission).

(Back to the Table of Contents)

2.3.2 Air Component Commander

(Future) The Air Component Commander (ACC) will normally be assigned reporting responsibility and limited correlation authority for all airborne contacts. A secondary ACC should be assigned for casualty configurations. As such, the ACC will be responsible for:

a. Correlation of organic and non-organic air track data prior to its injection into the CTP.

b. The deletion of tracks which have left the AOR, have returned to base, or are otherwise deemed invalid.

c. Maintaining the communications links / networks necessary to support the broadcast of the air picture to the CTP Manager (as designated by the CJTF or the on-scene commander).

(Back to the Table of Contents)

2.3.3 Ground Component Commander

The Ground Component Commander (GCC) will normally be assigned reporting responsibility and limited correlation authority for all ground tracks to at least two echelons below Corps, unless more detail is specified. All or part of this responsibility may be delegated by the GCC to a subordinate, as required. A secondary GCC should be assigned for casualty configurations. As such, the GCC will be responsible for:

a. Correlation of organic and non-organic ground track data prior to its injection into the CTP.

b. The deletion of tracks which have left the AOR, or are otherwise deemed invalid.

c. Maintaining the communications links / networks necessary to support the broadcast of the ground picture to the CTP Manager (as designated by the CJTF or the on-scene commander).

(Back to the Table of Contents)

2.3.4 Maritime Component Commander

The Maritime Component Commander (MCC) will normally be assigned reporting responsibility and limited correlation authority for all maritime contacts, including copying the broadcast from the Force Over-the-Horizon Track Coordinator (FOTC). All or part of this responsibility may be delegated by the MCC to a subordinate, as required. A secondary MCC should be assigned for casualty configurations. As such, the MCC will be responsible for:

a. Correlation of organic and non-organic maritime track data prior to its injection into the CTP.

b. The deletion of tracks which have left the AOR, or are otherwise deemed invalid.

c. Maintaining the communications links / networks necessary to support the broadcast of the maritime picture to the CTP Manager (as designated by the CJTF or the on-scene commander).

(Back to the Table of Contents)

2.3.5 Allied Participation

Distribution of the CTP to coalition partners will require that only data which is releasable to all members of the coalition be distributed. Alternatively, a separate allied / coalition network can be established that is operated at a classification releasable to the members of the coalition with a sanitization device (e.g., RADIANT MERCURY) used to provide this sanitized feed of releasable data to the coalition network.

(Back to the Table of Contents)

2.3.6 Other Agencies

The CJTF or the designated authority can request other agencies (e.g., DIA, NSA, CIA, NIMA) assistance in providing information as the mission / situation dictates. This information will be transmitted to the CTP Manager for incorporation into, and deconfliction with the CTP.

(Back to the Table of Contents)

2.4 Information Management Responsibilities

Raw PLI data can be injected into the CTP from many sensors and communications sources including organic, non-organic, theater, combined, communications links, and national sensors. Since data is available via multiple paths with different inherent characteristics (e.g., latency, accuracy, precision, format), it is possible that multiple sources will provide raw PLI data (i.e., a contact report) on the same physical object in the battlespace. Information managers (e.g., injection nodes, correlation nodes) must have guidance and commensurate authority to resolve all resulting conflicts that may occur in the PLI component of the CTP. Much of this will be accomplished through the process of correlation at the appropriate designated correlation site, see Paragraph 2.7, Correlation Responsibilities..

(Back to the Table of Contents)

2.5 Track Management Responsibilities

(Future) This paragraph will be expanded in the future to address permissions at each node for access to track management functions. Track management functions include the ability to update, delete, merge, associate, and disassociate, both contact reports and tracks in the CTP. These functions directly affect the ability to maintain an accurate depiction of the battlespace via the CTP. The operators at each site / node should not be denied the ability to modify their depiction of the battlespace for a specific mission. However, this modification should not necessarily affect the overall depiction of the battlespace for all command levels in the AOR. The capability to assign permissions / roles for each site will become more technically and operationally feasible as we move to a more network-centric architecture.

(Back to the Table of Contents)

2.6 Filtering Responsibilities

Correlation and Dissemination (or CTP Reporting) nodes will have the ability to apply both tactical track and information filters. The filtering criteria available for selection are as follows: time of report based; geo-location based; and, track/information type (i.e., reporting source, track category, track identification).

The filtering capability allows for the exclusion of data from outside the area of responsibility (AOR) or to/from coalition partners, when appropriate. PLI injection nodes may apply limited display or processing filters, as appropriate. However, it is important that these nodes disseminate all raw PLI data to the designated correlation and dissemination nodes in order to maintain a complete and accurate CTP.

The designated CTP manager may create and disseminate filter criteria to all nodes to ensure that the CTP is initially received and displayed in a similar manner, as at Primary Sites. The filters may be modified at receiving nodes for tailoring of the CTP to support specific mission requirements, see Paragraph 2.2, Planning / Policy, for additional guidance on this subject.

(Back to the Table of Contents)

2.7 Correlation Responsibilities

Correlation is a key function of information management. Defined earlier, Correlation is the process of extending an existing track or creating a new track with an incoming contact report. This is the automated process of integrating incoming contact reports from multiple sources into tracks. The goal is to assemble all reports associated with one physical object into a single track in the CTP. Track Managers / Coordinators located at designated Correlation and Dissemination Nodes (Primary Sites) will utilize automated and manual capabilities to correlate and associate (see Paragraph 1.2C) incoming contact reports to tracks in the CTP.

Component Commanders, lower echelons, and other data providing organizations (e.g., combined forces, other agencies) may have designated correlation responsibility for particular types of tracks based upon assigned responsibilities (e.g., from CJTF) and a combination of AOR, organic sensors, and other track attributes, see Paragraph 2.2, Planning / Policy, and Paragraph 2.6, Filtering Responsibilities for additional information. Deconfliction of the CTP is the responsibility of the Primary Site Track Managers / Coordinators.

(Future) For the PLI Component of the CTP, tracks may contain multiple contact reports from one or more distinct sensors. The Track Managers / Coordinators append, both automatically and manually, a unique track identifier (e.g., track number) to each distinct track object that can be associated to other contact reports and tracks. This aids in the process of multi-sensor correlation, for which the goal is one track in the CTP for each physical object in the battlespace.

(Back to the Table of Contents)


3.1 Defense Information Infrastructure Common Operating Environment

The DII COE is a "plug and play" open architecture. It is not a system, but rather a foundation for building an open system. The DII COE itself is made up of different components, including the kernel, the Universal Communications Processor, the Joint Mapping Tool Kit, and the Tactical Management Services. The kernel consists of the runtime environment, the system administrator utilities, the security services, the developer and runtime tools, and the developer's tool kit. The Universal Communications Processor (UCP) has been constructed on top of the DII COE kernel to meet the DII COE Communications Service requirements specifically in the area of message based data exchange for both text and binary messages. The Joint Mapping Tool Kit (JMTK) provides the charting component of the DII COE. It is comprised of three modules, including visual, spatial database, and analysis. The Tactical Management Services (TMS) includes correlators, track database management, GUIs for track data access, broadcasting capability, track plotting, and overall track management.

The DII COE represents a departure from traditional development programs. It emphasizes incremental development and fielding to reduce the time required to put new functionality into the hands of the warrior, while not sacrificing quality nor incurring unreasonable program risk or cost. The development approach is sometimes described as "build a little - test a little - field a lot" philosophy.

One of the benefits of being a DII COE compliant mission application, is the relatively simple portability to the USMC C2 environment (MSBL) and to Navy platforms (JMCIS), including those without either an ACDS or AN/KSQ-1 system.

(Back to the Table of Contents)

3.2 Communications

3.2.1 Available Interfaces

Current PLI programs include GSI, PLIS, JPI, SABER, and AN/KSQ-1.

a. JPI and PLIS were a combined effort to inject PLI data into Tdbm as link tracks. PLIS maintained the interface to the PLRS. JPI used PLIS APIs to receive the track data, perform processing on the data, and inject the necessary information into Tdbm. Currently there is an effort underway to incorporate the communications interfaces from PLIS into JPI.

  1. GSI provides an interface to the SAT, which maintains another interface to EPLRS. Although GSI required another interface, it made use of the same processing and injection code that was built for JPI. GSI injects PLI data into Tdbm as link tracks.
  1. The SABER segment contains an interface to the SABER C2 beacon, and a module for the processing and injection of SABER PLI data into Tdbm as unit and platform tracks. The SABER segment also includes mission-specific applications.
  1. AN/KSQ-1 contains an interface to PLRS via a GPSIU. AN/KSQ-1 processes the data and injects PLI tracks into Tdbm as platform and unit tracks. This system also includes mission-specific applications.
(Back to the Table of Contents)

3.2.2 Commonality

Each of the PLI sources that exist today transmit PLI information in a format different than the other PLI sources. Each of the segments and / or systems that use the PLI data process the data in a unique manner. The systems do not all use the same track type to inject the data into the database. This makes database correlation impossible. Bringing these interfaces together under one architecture will help to move the PLI picture closer to becoming a Coherent Tactical Picture, while at the same time saving money by reducing duplication of efforts, differences in processing, and management of multiple modules.

(Back to the Table of Contents)

3.2.3 Expandability / Scalability

Making use of the UCP provided by the DII COE allows the flexibility for adding additional communications interfaces at anytime without modifying the existing core system. The architecture has been designed such that additional PLI sources, as they are fielded , can easily be incorporated into the software, hence the CTP.

(Back to the Table of Contents)

3.2.4 Independence

Each PLI source is required to meet the needs of a separate user community, while at the same time providing PLI data to the common PLI processing module. It must be noted that in addition to PLI data, most of the PLI communications interfaces exchange additional types of information. Each interface must have access for mission specific applications to transmit and receive mission specific data across the interface, given that all rules for the specific interface are adhered to.

(Back to the Table of Contents)

3.2.5 Common Message Structure (Future)

One goal of the CSFAB PLI SET is to develop one common message structure (i.e., one standard format) that is a superset of those currently defined. This will address the backward compatibility concerns of existing systems while providing a migration path as current PLI systems are upgraded. In addition, it will provide requirements and metrics for future PLI system. Achievement of this goal will support the timely generation of the PLI component of the CTP.

(Back to the Table of Contents)

3.3 Processing

3.3.1 Injection

Although each PLI source adheres to a different specification for the formatting of PLI data messages, the PLI correlator will accept a single super-set of information provided by the PLI sources. This superset will help to define a standard for message traffic among PLI sources. All PLI data will be injected into the database in the same format, which will enable correlation and make it easier for the operator to view / analyze the data.

(Back to the Table of Contents)

3.3.2 Correlation

PLI tracks from the different sources and sensors will be correlated to present the operator one coherent PLI picture, that displays the most accurate position available on the track. All reports and information that were used to perform the correlation and obtain the most accurate position information will be available for viewing by the operator. The operator will also have the ability to turn on and off the correlation capability.

(Back to the Table of Contents)

3.3.3 Interoperability

The injection of the correlated PLI Coherent Tactical Picture into TMS will make it available for widespread distribution to Navy and Marine Corps units. From TMS the PLI CTP will have the Universal Communications Processor available to enable the dissemination of the picture to other users. The PLI CTP can be transmitted to ACDS or AEGIS via the Combat Systems Interface which adheres to IDS WS 19702. It can also become part of the Common Operational Picture (COP) and be distributed to all nodes in the AOR, theater, or world-wide participating in the COP.

(Back to the Table of Contents)

3.3.4 Multi-Source / Multi-Sensor Correlation (Future)

The goal for future correlation processing of raw PLI data is a single multi-source / multi-sensor correlation algorithm capable of generating a single track for each physical object in the battlespace. This will provide an accurate and timely depiction of the PLI Component of the CTP. For additional insight into current limitations (e.g., correlation, association), see Paragraph 1.2, Background, Paragraph 2.4, Information Management Responsibilities, and Paragraph 2.7, Correlation Responsibilities.

(Back to the Table of Contents)

3.4 Display

The PLI Coherent Tactical Picture will be displayed on a DII COE workstation. Given the display filtering capability of the PLI system, each operator will be able to manipulate the display in support of specific mission requirements. This architecture will allow for the same data to be used for both Situational Awareness (High Echelon C2) and Mission Support (e.g., NSFS, etc.). In addition, the PLI system will support the following display options :

a. Battlefield View

The operator will have the ability to "roll-up" the battlefield, by either selecting the echelon level by which to display tracks, or by creating and applying task organizations to the current depiction of the battlefield.

b. Source Information

The operator will have the ability to display the PLI picture based on the reported source of the raw PLI data.

c. Track Symbology (Future)

Track symbology will be selectable for PLI with the following minimum options :

- MIL-STD 2525A

- APP-6


(Back to the Table of Contents)

4.0 Infrastructure Requirements

4.1 Hardware

The DII COE supports both Sun and Hewlett Packard platforms. The DII COE hardware can be selected and configured to meet the requirements of performance and functionality for a given system. A system required to process multiple high speed PLI inputs will require a high-end workstation with a large amount of RAM. Systems will a lighter processing load will be able to use a lower-end workstation and smaller amounts of RAM.

In the future, as JMCIS '98 and the PC-based version of DII COE evolve, the PLI system will add the PC to the list of supported platforms.

The hardware is scaleable to support the needs of different end users and their missions.

(Back to the Table of Contents)

4.2 Software

The PLI system will reside on a machine running DII COE version 3.1 or higher. All interfaces to PLI source providers will be integrated into one common PLI processor. This processor will be responsible for handling communications with external PLI sources, message processing, track management, track display, and data distribution. The PLI processor will provide sufficient access to allow mission applications to perform their function external to the PLI processor.

The Enhanced Position Location Information Segment (EPLIS) will be a DII COE based segment, hence making it available to a wide range of systems, including MSBL and JMCIS. EPLIS will integrate all interfaces to external PLI sources. With PLI interfaces centrally located in one segment changes to interfaces and processing will be simplified. All PLI data will be decoded to the same format, making processing of the data more efficient. The data will be processed by the PLI correlator which will perform multi-sensor and multi-source correlation. PLI tracks will be injected into TMS and hence be available for wide-spread distribution. See figure 4.1.

  • Figure 4.1. PLI CTP Architecture

    (Back to the Table of Contents)

    4.3 Network

    In the case where the PLI system resides in the same local area with other DII COE workstations, the PLI system will be required to reside on and communicate with other systems on the DII COE network. When the PLI system is a stand alone machine, it must be capable of processing PLI data without the support of additional machines on the network.

    Interfaces to external PLI sources/systems must be attached to the hardware running the PLI correlator, attached to another DII COE system on the same local area network, or available via the wide area network (SIPRNET, etc.).

    (Back to the Table of Contents)


    This document provides the first step in the natural progression or evolution to a Joint PLI CONOPS describing the PLI Component of the Coherent Tactical Picture. The CTP is a component of the Joint Common Operational Picture (COP) for a specific AOR.

    Paragraph 1.2, Background, identifies the systems (e.g., AN/KSQ-1, Applique, PLRS, EPLRS, and SABER) that either currently provide or will provide PLI. In addition, it eludes to current fielding strategies, or the lack thereof, and the major problems associated with these strategies.

    The judicious application and tailoring of this document can help to minimize some of the problems described, such as: data latency; reporting accuracy; precision; track association; and, contact and track correlation. This document provides guidance from an operational perspective, and as such, it cannot hope to solve the technical deficiencies that exist within the currently released systems.

    The second stated objective in Paragraph 1.3, Objectives, is to provide a vision for the future. The following paragraphs describe the DII COE compliant Enhanced Position Location Information Segment (EPLIS) architecture. This architecture provides a migration path to a common solution for the PLI Component of the CTP that leverages the investments made to date on the currently deployed systems.

    The EPLIS architecture begins to leverage other DII COE and Naval COE based PLI initiatives such as: SABER; GSI for EPLRS; and, the USMC's JPI for PLRS. EPLIS 1.0 Beta to be highlighted at the Battle Lab, Fort Gordon will present a rudimentary capability for a "Battlefield Roll-up" display capability based upon task organizations developed in response to Task Orders.

    The DII COE compliant approach allows for the reuse of a collection of software which will provide access to the following: existing combat systems interface to both AWS and ACDS; correlation (single source / sensor) and filtering processes; advanced display features; and, communications services such as OTCIXS, TADIXS A, TADIXS B, and TADIL J (near-term).

    EPLIS is migrating toward one common message standard to reduce / eliminate backward compatibility and interoperability problems. This will reduce the future costs of adding emerging PLI sensors / sources to the architecture by insulating the majority of core services from change.

    EPLIS development is based on the Evolutionary Software Development Model, thus evolving capabilities through incremental improvement (i.e., conforms to the DII COE strategy "build a little, test a little, field a lot!").

    Further benefits of the DII COE approach for EPLIS, are the move toward hardware independence. EPLIS is available on the Hewlett Packard and SUN platforms today. In the future, it will be available on the PC (Windows NT) based platforms. In addition, EPLIS will operate on any DII COE compliant system (e.g., USMC's MSBL, USN's JMCIS, USA's AGCCS, Joint GCCS, etc.).

    To fully realize a timely and accurate, shared Coherent Tactical Picture, future upgrades to EPLIS must incorporate the following capabilities:

    a. Operator selection of alternate symbol sets (e.g., MIL STD 2525A, APP 6)

    b. Multi-source / Multi-sensor correlation capability to accurately depict one track for each physical object in the battlespace.

    c. Enable full translation of PLI from all sensors / sources to target systems (e.g., JMCIS, MSBL, OTCIXS, TADIL J).

    (Back to the Table of Contents)

    Appendix A
    List of Abbreviations

    ACC Air Component Commander

    ACDS Advanced Combat Direction System

    AN/KSQ-1 Amphibious Assault Direction System

    AOR Area of Responsibility

    AOU Area of Uncertainty

    API Application Program Interface

    ASCID All-Service Combat Identification Demonstration

    AWS Aegis Weapons System

    BUU Basic User Unit

    C2 Command and Control

    C4I Command, Control, Communications, Computers, and Intelligence

    CC Component Commander

    CIA Central Intelligence Agency

    CINC Commander in Chief

    CJCSI Chairman of the Joint Chiefs of Staff Instruction

    CJTF Commander, Joint Task Force

    CmTP Common Tactical Picture

    CONOPS Concept of Operations


    COP Common Operational Picture

    CSAR Combat Search and Rescue

    CSFAB Combat Systems Functional Allocation Board

    CSI Combat Systems Interface

    CTP Coherent Tactical Picture

    DASN Deputy Assistant Secretary of the Navy

    DIA Defense Intelligence Agency

    DII COE Defense Information Infrastructure Common Operating Environment

    EPLIS Enhanced Position Location Information System

    EPLRS Enhanced Position Location Reporting System

    EW Electronic Warfare

    FOTC Force Over-the-Horizon Track Coordinator

    GCC Ground Component Commander

    GCCS Global Command and Control System

    GPSIU Global Positioning System Interface Unit

    GSI GCCS - SAT Interface


    IDS Interface Design Specification

    IPT Integrated Process Team

    JMCIS Joint Maritime Command Information System

    JMTK Joint Mapping Tool Kit

    JPI JMCIS - PLIS Interface

    JTIDS Joint Tactical Information Distribution System

    JOPES Joint Operation, Planning and Execution System

    LCAC Landing Craft, Air Cushion

    MAGTAF Marine Air Ground Task Force

    MCC Maritime Component Commander

    METOC Meteorological and Oceanographic

    MSBL MAGTAF C4I Software Baseline

    NAVSEA Naval Sea Systems Command

    NIMA National Imagery and Mapping Agency

    NMCC National Military Command Center

    NSA National Security Agency

    NSFS Naval Surface Fire Support

    OPLANS Operational Plans

    OPORDERS Operational Orders

    OTCIXS Officer-in-Tactical Command Information Exchange System

    PLI Position Location Information

    PLIS Position Location Information System

    PLRS Position Location Reporting System

    RAM Random Access Memory

    SABER Situational Awareness Beacon with Reply

    SAT Situational Awareness Terminal

    SET Systems Engineering Team


    SIPRNET Secret Internet Protocol Router NETwork

    SORTS Status of Resources and Training System

    TAD Theater Air Defense

    TADIL A Tactical Digital Link A

    TADIL J Tactical Digital Link J

    TADIXS A Tactical Digital Information Exchange System A

    TADIXS B Tactical Digital Information Exchange System B

    Tdbm Tactical Database Manager

    TMS Tactical Management Services

    UCP Universal Communications Processor

    US United States

    Windows NT Windows New Technology

    WS Weapons Specification

    (Back to the Table of Contents)

    Appendix B
    Reference Documents

    (Back to the Table of Contents)