UNCLASSIFIED

Army Positioning, Navigation, and Timing (PNT)

Reference Architecture

1 July 2018

Version 1.0

DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

UNCLASSIFIED

ii

UNCLASSIFIED

Executive Summary

The 22 April 2013, Army Acquisition Executive (AAE) Memorandum: Army Positioning, Navigation, and Timing (PNT) System of Systems Architecture (SoSA) Strategy contained three strategic goals: “reduce PNT requirement inefficiencies/redundancies, decrease Warfighter vulnerabilities and [...] provide an affordable migration path to the Military Code (M-Code).” The Army PNT Reference Architecture (RA) enables the development of a PNT SoSA to help attain these strategic goals. Application of the PNT RA will also help achieve the Army’s vision for PNT with Assurance: providing operational and institutional Army Forces PNT information with assurance under the complete range of threat conditions in an affordable, upgradeable, and adaptable manner. This vision represents an end state that includes closing the PNT access and integrity gaps identified in the Positioning, Navigation, and Timing (PNT) Assurance Initial Capability Document (ICD) approved 30 April 2010.

The PNT RA will guide and constrain the development of all Army systems consuming or providing PNT Information with Assurance. PNT Information with Assurance is defined as trustworthy PNT Information that has been developed via access to one or more independent sources, depending upon PNT threat conditions. It should be noted that PNT includes, but is not limited to, the Global Positioning System (GPS).

Architecture specifications identify and define system components and their inter-relationships in order to focus and scope system engineering to facilitate reducing development and lifecycle risks, primarily those from interoperation and integration. Given the potential for multiple technical approaches, different implementations and evolving capabilities, specific architectures may be governed by a more general framework or reference architecture such as this one. A reference architecture serves to manage exactly how abstract, common and generic requirements are refined by solution architecture specifications, to include technical approaches and technical architecture specifications of technologies, into concrete, testable system specifications.

Version 1.0 of the PNT RA focuses on PNT distribution with an initial set of PNT RA elements, i.e., principles, technical positions, patterns, and vocabulary. Future versions will focus on identifying PNT related capabilities needed to provide PNT Information with Assurance and add:

PNT RA elements needed to support all Army systems

Implementation guidance that will guide the implementation of systems to help ensure that they consume or provide PNT Information with Assurance when operating in their target PNT threat conditions

Assessment criteria that will assess whether applicable Army systems are in compliance with this PNT RA

The PNT RA’s primary audience consists of Assistant Secretary of the Army for Acquisition Logistics, and Technology (ASA(ALT)) architects, systems engineers, and system and platform product owners.

UNCLASSIFIED

iii

UNCLASSIFIED

Contents

1. Introduction ............................................................................................................................ 1

1.1 Purpose ....................................................................................................................... 1

1.2 Contents ...................................................................................................................... 1

1.3 Applicability ................................................................................................................. 2

1.4 Scope .......................................................................................................................... 2

1.5 Background ................................................................................................................. 2

1.6 Army PNT RA Overview .............................................................................................. 3

1.7 Stakeholders ............................................................................................................... 4

1.8 Key Authoritative Sources ........................................................................................... 5

1.9 Tools Used .................................................................................................................. 5

1.10 DoDAF Architecture Models in the Army PNT RA ...................................................... 5

1.11 Document Conventions ............................................................................................... 6

2. Context ................................................................................................................................... 7

2.1 Guiding Principles ....................................................................................................... 7

2.2 Constraints and Assumptions ...................................................................................... 9

2.2.1 Constraints ...................................................................................................... 9

2.2.2 Assumptions .................................................................................................... 9

3. PNT with Assurance Vision and High Level Operational Concept ....................................... 10

3.1 Army Vision for PNT with Assurance ........................................................................ 10

3.1.1 Army PNT RA CV-1 Vision Description ......................................................... 12

3.1.2 Army PNT RA CV-1 Goals Descriptions ........................................................ 12

3.1.3 Army PNT RA CV-1 Capability Descriptions ................................................. 13

3.1.4 Army PNT RA CV-1 Joint Capability Areas (JCAs) ....................................... 13

3.1.5 DoDAF Model Support of Army PNT RA CV-1 Enterprise Goals .................. 13

3.2 Operational Concept for PNT with Assurance ........................................................... 14

4. Architecture Patterns ........................................................................................................... 17

4.1 Capability Configuration and Structural Rules ........................................................... 17

4.1.1 Capability Configuration Description ............................................................. 17

4.1.2 Capability Configuration Structural Rules ...................................................... 18

4.2 Systems Interface Patterns ....................................................................................... 20

4.2.1 Systems Interface Description ....................................................................... 20

4.2.2 Army PNT RA SV-2 Systems Resource Flow Description Port Descriptions 23

UNCLASSIFIED

iv

UNCLASSIFIED

4.2.3 Army PNT RA SV-2 Systems Resource Flow Description Information Exchange Standards ................................................................................................. 24

4.2.4 Army PNT RA SV-2 Systems Resource Flow Description Port Related Standards .................................................................................................................. 25

4.2.5 Army PNT RA SV-2 Systems Resource Flow Description Interface-Standards Mapping ..................................................................................................................... 25

4.3 System Function Pattern ........................................................................................... 26

4.3.1 Army PNT RA SV-4 Systems Functionality Flow Description System Function Descriptions ............................................................................................................... 27

4.3.2 Army PNT RA SV-4 Systems Functionality Flow Description Additional Resource Descriptions .............................................................................................. 28

4.4 Army PNT RA Architecture Pattern Rules ................................................................. 29

4.5 PNT Distribution Pattern ............................................................................................ 29

5. Technical Position ................................................................................................................ 30

List of Tables Table 1. Authoritative Sources ...................................................................................................... 5

Table 2. DoDAF Architecture Models in the Army PNT RA .......................................................... 5

Table 3. Army PNT RA Guiding Principles ................................................................................... 7

Table 4. Army PNT RA Version 1.0 Interfaces ............................................................................. 9

Table 5. DoDAF Model Support of Army PNT RA CV-1 Enterprise Goals ................................. 13

Table 6. Army PNT RA Systems ................................................................................................. 17

Table 7. Structural Rules ............................................................................................................ 19

Table 8. Army PNT RA SV-1 Systems Interface Description Interface Rules............................. 21

Table 9. Army PNT RA SV-2 Systems Resource Flow Description Port Rules .......................... 24

Table 10. Army PNT RA SV-2 Interface-Standards Mapping ..................................................... 25

Table 11. Army PNT RA SV-2 Systems Resource Flow Description Interface Rules ................. 26

Table 12. Army PNT RA StdV-1 ................................................................................................. 30

Table 13. Army PNT RA StdV-2 ................................................................................................. 31

Table 14. Army PNT RA AV-2 .................................................................................................... 38

List of Figures Figure 1. Army PNT RA Relationships .......................................................................................... 1

Figure 2. CV-1 Army Vision for PNT with Assurance .................................................................. 11

Figure 3. OV-1 High-Level Operational Concept Graphic for PNT with Assurance .................... 15

Figure 4. Army PNT RA SV-1 Capability Configuration Diagram ............................................... 18

UNCLASSIFIED

v

UNCLASSIFIED

Figure 5. Army PNT RA SV-1 Systems Interface Description .................................................... 21

Figure 6. Army PNT RA SV-2 Systems Resource Flow Description........................................... 23

Figure 7. Army PNT RA SV-4 Systems Functionality Flow Description ...................................... 27

Figure 8. PNT Distribution Pattern .............................................................................................. 29

Figure 9. SV-2 Alignment Example ............................................................................................. 32

List of Appendixes Notional Usage of the Army PNT RA ...................................................................... 32

Abbreviations and Acronyms ................................................................................... 33

Glossary of Terms ................................................................................................... 35

Army PNT RA All Viewpoint Views .......................................................................... 38

References .............................................................................................................. 46

UNCLASSIFIED

1

UNCLASSIFIED

1. Introduction

The 22 April 2013, Army Acquisition Executive (AAE) Memorandum, Army Positioning, Navigation, and Timing (PNT) System of Systems Architecture (SoSA) Strategy, contained three strategic goals: “reduce PNT requirement inefficiencies/redundancies, decrease Warfighter vulnerabilities and [...] provide an affordable migration path to the Military Code (M-Code).” The Army PNT Reference Architecture (RA) enables the development of a PNT SoSA to help attain these strategic goals. Application of the PNT RA will also help achieve the Army’s vision for PNT with Assurance1: providing operational and institutional Army Forces PNT information with assurance under the complete range of threat conditions in an affordable, upgradeable, and adaptable manner. PNT Information with Assurance is defined as trustworthy PNT Information that has been developed via access to one or more independent sources, depending upon PNT threat conditions. Note that PNT includes, but is not limited to, the Global Positioning System (GPS).

1.1 Purpose

The purpose of the Army PNT RA is to guide and constrain the development of Army systems consuming or providing PNT Information with Assurance, as depicted in Figure 1.

Figure 1. Army PNT RA Relationships

1.2 Contents

The Army PNT RA described herein is Version 1.0. Version 1.0 of the Army PNT RA will focus on:

PNT Distribution

An initial set of PNT RA elements o Principles o Technical positions o Patterns o Vocabulary

1 The terms “PNT with Assurance” and “PNT Information with Assurance” refers to the PNT data provided by the PNT Module; that module will always provide PNT data with or without assurance, but the goal is always to provide it with assurance.

UNCLASSIFIED

2

UNCLASSIFIED

Future versions will include:

A complete set of principles, technical positions, patterns, and a vocabulary supporting all Army systems

Implementation guidance for providing PNT Information with Assurance

Assessment criteria

The contents and development schedule of the PNT RA are described in more detail in Section 1.6.

1.3 Applicability

The Army PNT RA applies to all Army-developed or -acquired systems that are consuming or providing PNT Information. This guidance will be used throughout system development, from concept to implementation and test, as well as during system modernization or addition of PNT functionality.

1.4 Scope

The operational scope of the Army PNT RA consists of all operational and institutional Army Forces under the complete range of threat conditions both deployed and at home station. The technical scope of the Army PNT RA consists of the PNT Module, which includes a capability to distribute PNT Information with Assurance to PNT Client System(s), and sources of PNT, i.e., devices, systems, or sensors, internal or external to the PNT Module, that provide information enabling the determination of current position, velocity, and time: GPS Satellite, Pseudo-GPS Satellite, and Non-GPS PNT Source. It also includes the PNT Module interfaces and the standards for those interfaces. (Note: Command and Control [C2] capabilities for the employment of Pseudo-GPS Satellite are not addressed in this version of the PNT RA. They will be included in Version 2.0 if the necessary information is available; otherwise, they will be included in Version 3.0. Multiple security domain related capabilities are beyond the scope of the PNT RA and are not included.)

The Army PNT RA identifies those salient features of the PNT portion of a system’s architecture, which, when incorporated, ensure the consumption or production of PNT Information with Assurance. The PNT RA does not provide all the details necessary to build the PNT portion of a system.

1.5 Background

As explained in An Evolving Joint Perspective: US Joint Warfare and Crisis Resolution In the 21st Century (JWCR), future joint conflict will be characterized by rapid employment of capabilities in distributed, parallel operations applying adaptive power to achieve operational and strategic objectives. The battle space of the 21st century, in which the Joint Force will operate, will transcend the physical environment to include the cyber domain and time. Success will require the coordination of parallel and distributed planning and execution of network-centric, effects-based expeditionary warfare. PNT capabilities are critical to the Joint Force Commander achieving full spectrum dominance through unified action and to the conduct of Joint decisive operations across the range of military operations as outlined in the Capstone Concept for Joint Operations (CCJO).

The Joint Capabilities Document (JCD) for Positioning, Navigation, and Timing defines PNT as a joint capability, with three constituent capabilities (PNT), as defined in the PNT Functional Area Analysis.

UNCLASSIFIED

3

UNCLASSIFIED

Positioning: the ability to accurately and precisely determine one’s location and orientation two dimensionally (or three dimensionally, when required) referenced to a standard geodetic system (World Geodetic System 1984 [WGS 84] height above ellipsoid [HAE] or other vertical datum as directed in CJCSI 3900.01D), anywhere within the battle space and within user defined timeliness parameters.

Navigation: the ability to determine current and desired position and apply corrections to course, orientation, and speed to attain the desired position anywhere within the battle space, within user-defined, timeliness parameters.

Timing: the ability to acquire accurate and precise time from a standard (Coordinated Universal Time [UTC]/US Naval Observatory [USNO]) anywhere within the battle space, and within user-defined, timeliness parameters. Timing includes time transfer.

The US Army Training and Doctrine Command (TRADOC) identified two primary capability gaps, quoted below, in the PNT Assurance Initial Capability Document (ICD) approved 30 April 2010.

Access gap: inability to access PNT information in impeded conditions

Integrity gap: inability to determine validity and accuracy of PNT information

These gaps were key motivators for the Army’s vision of PNT with Assurance. The guiding principles of the Army PNT RA, detailed below in Section 2.1 Guiding Principles, establish high-level foundational statements of rules, culture, and values that drive technical positions and patterns for each of the potential technical approaches and implementations. The Implementation Guidance that will be part of the Army PNT RA v2 will detail how each of the technical approaches will address both the Access and Integrity gaps.

1.6 Army PNT RA Overview

As mentioned in Section 1.2, the Army PNT RA includes a set of PNT RA elements: principles, technical positions, patterns, and a vocabulary. Principles are high-level foundational statements of rules, culture, and values that drive technical positions and patterns. Technical positions are, essentially, standards that need to be followed as part of implementations. Patterns are generalized architecture representations, e.g., diagrams that show relationships between elements of the architecture. The vocabulary consists of terms that are used in the PNT RA and their definitions. This set will grow with each version of the PNT RA.

Version 1.0 of the PNT RA focuses on PNT distribution using an initial set of PNT RA elements.

Version 2.0 of the PNT RA will focus on identifying capabilities needed to provide PNT Information with Assurance and add the following.

PNT RA elements supporting aviation, ammunition, and watercraft domains, air & missile defense, and training capabilities

Implementation guidance that will guide the implementation of systems to help ensure that they consume or provide PNT Information with Assurance when operating in their target PNT threat conditions

Assessment criteria that will be used to assess whether Army systems that consume or produce PNT Information are in compliance with this PNT RA

Version 3.0 of the PNT RA will add the following.

Implementation guidance updates

Assessment criteria updates

Emerging PNT standards

UNCLASSIFIED

4

UNCLASSIFIED

(Note: C2 of Pseudo-GPS Satellites will be included in Version 2.0 or Version 3.0 depending upon the availability of necessary information and is, therefore, not specifically identified as being in either.)

Future versions of the PNT RA will add material to address additional domains, such as aviation, or functional areas, such as implementation guidance. Therefore, the expected impact on domains addressed in previous versions is minimal. However, the effect of including C2 of Pseudo-GPS Satellites is unknown. An example of how the PNT RA would be used is contained in Appendix A.

1.7 Stakeholders

Primary stakeholders and their roles for the Army PNT RA are as follows.

a. Common Operating Environment (COE) Computing Environment (CE) architects and systems engineers will align with the PNT RA in achieving required functionality per the 22 April 2013 AAE Memorandum: Army PNT SoSA Strategy.

b. ASA(ALT) architects, systems engineers, and system and platform product owners. c. The Army acquisition community will use the Army PNT RA to help guide science and

technology investment initiatives so resulting products can be used with minimum disruption to existing systems.

UNCLASSIFIED

5

UNCLASSIFIED

1.8 Key Authoritative Sources

The authoritative sources identified in Table 1 guided development of the Army PNT RA.

Table 1. Authoritative Sources

Document Title Description

Army PNT SoSA Strategy memo, 22 Apr 2013

Published by the Office of the ASA(ALT). This memo describes the Army’s need for a system of systems architecture for Army PNT.

DoDI 4650.08 PNT and Navigation Warfare (NAVWAR), 5 Feb 2015

Establishes policy and assigns responsibilities for integrating PNT and NAVWAR across the DoD and for the security of PNT information related to the development, acquisition, and operational use of PNT information sources and PNT information-dependent systems.

CJCSI 6130.01F 2016 CJCS Master PNT Plan (MPNTP), 30 Sept 2016

Provides overarching guidance and procedures for the planning, use, and management of the DoD PNT systems either owned or contracted for use to meet operational warfighter requirements.

DoD Reference Architecture Description Guidance Document, 18 Jun 2010

Developed by the Office of the Assistant Secretary of Defense, Networks and Information Integration (OASD/NII)/DoD CIO. This document describes the intended use of reference architectures within the DoD.

Joint Capabilities Document for PNT, 26 Sept 2006

Identifies the PNT capabilities required by the Joint Warfighter to assure PNT in any environment or condition. These capabilities will be the basis for future PNT solution development across the range of doctrine, organization, training, materiel, leadership and education, personnel, and facilities (DOTMLPF) possibilities, by the services and agencies to meet the Warfighters’ needs.

1.9 Tools Used

The Army PNT RA is being developed using the architecture modeling tool MagicDraw® with Unified Profile for the DoD Architecture Framework (AF) (DoDAF) and the British Ministry of Defence (MOD) AF (MODAF) (UPDM) 2, System Modelling Language (SysML®), and Microsoft PowerPoint®. The completed architecture will be stored in, and accessible via, the Army Capability Architecture Development and Integration Environment (ArCADIE) (https://cadie.army.mil/Cadie/Portal/Default.aspx).

1.10 DoDAF Architecture Models in the Army PNT RA

Table 2 depicts the DoDAF models included in the Army PNT RA. Sections 2.1 and 3.1.5 describe how these models support the PNT RA guiding principles and how application of the PNT RA via these views helps the Army to achieve its vision of PNT with Assurance.

Table 2. DoDAF Architecture Models in the Army PNT RA

DoDAF Model Description/Contents Appendix/Figure/Table

AV-1 Overview & Summary Information

Describes the purpose, scope, and context of the Army PNT RA

Sections 1, 2.2, & 3.1

AV-2 Integrated Dictionary

PNT RA vocabulary that defines the activities, capabilities, functions, information elements, rules, services, systems, and standards

Table 14

UNCLASSIFIED

6

UNCLASSIFIED

DoDAF Model Description/Contents Appendix/Figure/Table

CV-1 Vision Defines the Army’s vision for PNT with Assurance, the goals and sub-goals that must be met to achieve this vision, and the capabilities needed to meet them

Figure 2

OV-1 High-Level Operational Concept Graphic

Graphically depicts both the capabilities to be provided by the PNT SoS and their employment

Figure 3

SV-1 Systems Interface Description

Describes the logical patterns of the PNT-related systems and their interconnections and provides the context for the systems sending, receiving, and/or processing PNT data

Figure 4 and Figure 5

SV-2 Systems Resource Flow Description

Describes the pattern of the physical resources being used by the systems and the information resources being exchanged between them by way of interface ports and interface standards

Figure 6

SV-4 Systems Functionality Description

Identifies the functions typically performed by the PNT systems and the data flows among them

Figure 7

SV-10a Systems Rules Model

Identifies constraints that are imposed upon systems functionality due to some aspect of system design or implementation

SV-10a rules are presented with the applicable DoDAF models and are grouped as follows:

Table 7

Table 8

Table 9

Table 11

StdV-1 Standards Profile

Lists the known standards that must be applied to solutions developed to provide or consume PNT Information with Assurance

Table 12

StdV-2 Standards Forecast

Lists the emerging high-level policies and standards that may affect current and future solutions developed to provide or consume PNT Information with Assurance

Table 13

1.11 Document Conventions

When architecture elements appear in the document, they are capitalized. In Sections 3.1 (excluding sub-sections) and 3.2, architecture elements also are bolded to distinguish them from regular text.

UNCLASSIFIED

7

UNCLASSIFIED

2. Context

2.1 Guiding Principles

Table 3 depicts both the PNT RA’s guiding principles and the DoDAF architecture models that support each principle. Principles are high-level foundational statements of rules, culture, and values that drive technical positions and patterns.

Table 3. Army PNT RA Guiding Principles

Principle No.

Name Description Source/Rationale Supporting DoDAF Models

Supporting Model Element Types

PNT-01 PNT with Assurance

The Army will provide operational and institutional Army Forces PNT information with assurance under the complete range of threat conditions in an affordable, upgradeable, and adaptable manner.

This principle is derived from the Army’s vision for PNT with Assurance.

AV-1, AV-2, CV-1, OV-1

Vision, Enterprise Goals, Capabilities, Narratives

PNT-02 Stay ahead of the PNT Threat

To stay ahead of the PNT threat, the Army must use an open systems architecture that is flexible enough to accommodate additional capabilities without incurring expensive system or platform integration and certification costs.

This principle is derived from the Stay Ahead of the PNT Threat CV-1 Goal.

AV-1, AV-2, SV-1, SV-2, SV-4, SV-10a, StdV-1, StdV-2

Systems, System Functions, Ports, Interfaces, Exchange Elements, Standards

PNT-03 Increase PNT efficiencies and eliminate redundancies

To increase PNT efficiencies and eliminate redundancies, the number of GPS Receivers must be reduced via platform distribution of PNT, i.e., by providing the platform with a source of PNT that is then distributed to each of the client systems requiring PNT data.

This principle is derived primarily from the Increase PNT Efficiencies and Eliminate Redundancies CV-1 Goal.

AV-1, AV-2, SV-1, SV-2, SV-4, SV-10a, StdV-1, StdV-2

Systems, System Functions, Ports, Interfaces, Exchange Elements, Standards

PNT-04 Provide an affordable migration path to M-Code

To provide an affordable migration path to M-Code, the number of GPS Receivers and receiver form factors that have to be upgraded to M-Code must be reduced, therefore, reducing the cost to upgrade.

This principle is derived primarily from the Provide an Affordable Migration Path to M-Code CV-1 Goal.

AV-1, AV-2, SV-1, SV-2, SV-4, SV-10a, StdV-1, StdV-2

Systems, System Functions, Ports, Interfaces, Exchange Elements, Standards

UNCLASSIFIED

8

UNCLASSIFIED

Principle No.

Name Description Source/Rationale Supporting DoDAF Models

Supporting Model Element Types

DSD-22 Principle DSD-22

Unambiguous interoperability between highly interactive applications (particularly those requiring data translation and data integration) requires overt, formal, and precise specification of data exchange pathways and information content of the exchanged data (i.e., the description of the anticipated information that is being shared).

This is principle DSD-22 from the Army Information Architecture version 4.1 (Office, 2013).

AV-2, SV-1, SV-2, SV-10a, StdV-1, StdV-2

Systems, Ports, Interfaces, Exchange Elements, Standards

DADM-02 Principle DADM-02

Effective information sharing is based upon clear, unambiguous, and consistent management of structured data. Physical data models (schemas) are a necessary mechanism for managing the format and semantics of (i.e., the information conveyed by) structured data.

This is principle DADM-02 from the Army Information Architecture version 4.1 (Office, 2013).

AV-2, StdV-1, StdV-2

Exchange Elements, Standards

UNCLASSIFIED

9

UNCLASSIFIED

2.2 Constraints and Assumptions

The following constraints and assumptions are reflected in the Army PNT RA.

2.2.1 Constraints

These constraints were placed on this architecture.

C2 of some of the components in the Army PNT RA technical scope is necessary. However, the information, including specific components necessary to portray this C2, is not currently available. It will be incorporated into the PNT RA when available, i.e., Version 2.0 or 3.0.

Version 1.0 of the Army PNT RA only addresses data formats used in the interfaces identified in Table 4. An example of a PNT Client System is the Joint Battle Command-Platform (JBC-P).

The Army PNT RA focuses on the GPS user segment, which consists of the GPS Receiver equipment. This equipment receives the signals from the GPS Satellites and uses the transmitted information to calculate the user's three-dimensional position and time. The architecture also includes the space segment, but only to specify the interface standards between the space segment and the user segment.

The Army PNT RA implements services as a generic or abstract interface to the functionality. “A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” Business rules representing complex configuration management choices and options for PNT components are likewise hidden behind services.

Table 4. Army PNT RA Version 1.0 Interfaces

System PNT Module

GPS Satellite

Pseudo-GPS Satellite

PNT Client System

PNT Module X X X

GPS Satellite X

Pseudo-GPS Satellite

X

PNT Client System X

2.2.2 Assumptions

This architecture assumes the GPS will remain a source of PNT due to the current lack of a viable Non-GPS source of PNT with the GPS's near ubiquity and cost-effectiveness.

UNCLASSIFIED

10

UNCLASSIFIED

3. PNT with Assurance Vision and High Level Operational Concept

3.1 Army Vision for PNT with Assurance

The Army’s vision for PNT with Assurance, depicted in Figure 2, is to provide operational and institutional Army Forces PNT information with assurance under the complete range of threat conditions in an affordable, upgradeable, and adaptable manner. To achieve this vision, the Army must attain three goals.

Stay Ahead of the PNT Threat, both current and future

Provide an Affordable Migration Path to M-Code for PNT providing and consuming systems

Increase PNT Efficiencies and Eliminate Redundancies from duplicate PNT Modules, e.g., multiple GPS Receivers

To Stay Ahead of the PNT Threat, Army Forces must be able to:

Receive GPS signals using Military GPS Receivers

Obtain PNT under Electromagnetic interference (EMI) hazard and threat conditions, both intentional and unintentional

Obtain PNT without GPS, e.g., in complex terrain where GPS signals are blocked or impeded or when GPS is simply not available

Detect and Mitigate PNT Integrity Threats

Respond to New Threats and Incorporate New PNT Technology

The first four of these sub-goals depend on the capability to Obtain PNT Information with Assurance, which is trustworthy PNT Information that has been developed via access to one or more independent sources, depending upon PNT threat conditions. The last sub-goal depends on the capability to Facilitate PNT Systems Upgrade/Modification via Open Architectures that accommodate module level modification, including in situ reprogramming, and can upgrade more easily (both technically and financially) than complete system replacement.

To Provide an Affordable Migration Path to M-Code, the Army requires the ability to Facilitate PNT Systems Upgrade/Modification via Open Architectures, again to accommodate module-level versus system-level modification and upgrade and the ability to Distribute PNT Information where possible to local systems that need it, e.g., on a platform. The former capability may reduce cost by enabling systems to upgrade to M-Code capability versus replacing them with M-Code capable systems. The latter capability reduces the number of GPS Receivers and, therefore, the cost of migrating to M-Code or implementing any global change to GPS user equipment or to Non-GPS PNT Sources, e.g., inertial navigation systems (INS) or chip scale atomic clocks (CSAC).

Finally, to Increase PNT Efficiencies and Eliminate Redundancies, the Army requires the ability to Facilitate PNT Systems Upgrade/Modification via Open Architectures, in this case to configure PNT systems with only the capabilities (modules) required for anticipated threat conditions and the ability to Distribute PNT Information where possible to local systems that need it, e.g., on a platform. The former capability may reduce cost by enabling the initial fielding of PNT systems with only the cards/modules required. The latter capability reduces the number of PNT Modules needed and, therefore, the cost of implementing any global change to them.

UNCLASSIFIED

11

UNCLASSIFIED

Figure 2. CV-1 Army Vision for PNT with Assurance

UNCLASSIFIED

12

UNCLASSIFIED

Therefore, the three capabilities Obtain PNT Information with Assurance, Facilitate PNT Systems Upgrade/Modification via Open Architectures, and Distribute PNT Information enable the Army to achieve its vision of PNT with Assurance while directly supporting JCA 6.2.4 PNT.

3.1.1 Army PNT RA CV-1 Vision Description

The vision depicted in Figure 2 is PNT with Assurance, which describes how to provide operational and institutional Army Forces PNT information with assurance under the complete range of threat conditions in an affordable, upgradeable, and adaptable manner.

3.1.2 Army PNT RA CV-1 Goals Descriptions

The goals depicted in Figure 2 are as follows.

Detect and Mitigate PNT Integrity Threats: This goal is focused on the need to detect and mitigate GPS signal spoofing or other threats to PNT integrity.

Increase PNT Efficiencies and Eliminate Redundancies: This goal is focused on reducing the number of PNT Modules via platform distribution of PNT, providing the platform with a source of PNT that is then distributed to each of the client systems requiring PNT data. This will provide cost savings and allow enhancement of the single PNT Module’s capabilities that would likely not be possible technically and financially if multiple systems had to be updated (Coggins, 2015).

Obtain PNT under EMI Hazard and Threat Conditions: This goal is focused on the need to receive GPS signals or otherwise obtain PNT under electromagnetic interference (EMI) hazards and threats.

Obtain PNT without GPS: This goal is focused on the need to obtain PNT in complex terrain, such as dense vegetation, built-up urban and mountainous terrain, or when there simply is no GPS signal available.

Provide an Affordable Migration Path to M-Code: This goal is focused on ensuring that the Army can afford to update GPS Receivers to accept M-Code or replace them with GPS Receivers that can accept M-Code. Because the benefits of M-Code are best achieved when every platform and system for a warfighting element (e.g., a brigade combat team) uses M-Code, this goal requires that the number of GPS Receivers and receiver form factors be reduced to a minimum (Coggins, 2015).

Receive GPS Signals using Military GPS Receivers: This goal is focused on the need to use keyed military GPS Receivers that have additional technologies to increase access to GPS signals and filter out false signals, e.g., the Selective Availability Anti-Spoof Module (SAASM) and M-Code receivers after the M-Code migration.

Respond to New Threats and Incorporate New Technology: This goal is focused on the need to employ new capabilities or improvements to existing capabilities in response to technology advances or new threats.

Stay Ahead of the PNT Threat: This goal is focused on enabling an affordable, open systems architecture that is flexible enough to accommodate additional capabilities without incurring expensive system or platform integration and certification costs – a framework that enables a pathway for future innovation – all while providing PNT under current threat conditions (Coggins, 2015).

UNCLASSIFIED

13

UNCLASSIFIED

3.1.3 Army PNT RA CV-1 Capability Descriptions

The capabilities depicted in Figure 2 are as follows.

3.1.3.1 Distribute PNT Information

The ability to distribute PNT Information to local systems (e.g., on a platform), that need it, will increase PNT efficiencies and eliminate redundancies as described by Principle No. PNT-03 in Table 3 above.

3.1.3.2 Facilitate PNT Systems Upgrade/Modification via Open Architectures

The use of open architectures facilitates upgrades and modifications. An open architecture is a technical architecture that adopts open standards supporting a modular, loosely coupled and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure. A key enabler for open architecture is the adoption of an open business model, which requires doing business transparently to leverage the collaborative innovation of numerous participants across the enterprise permitting shared risk, maximize asset reuse, and reduce total ownership costs. The combination of open architecture and an open business model permits the acquisition of open systems architectures (OSAs) that yield modular, interoperable systems allowing components to be added, modified, replaced, removed, and/or supported by different vendors throughout the life cycle to drive opportunities for enhanced competition and innovation (DoD, 2013).

3.1.3.3 Obtain PNT Information with Assurance

Ability to obtain trustworthy PNT Information that has been developed via access to one or more independent sources, depending upon PNT threat conditions. This includes receiving GPS signals using military GPS Receivers, obtaining PNT under EMI hazard and threat conditions, obtaining PNT without GPS, and detecting and mitigating PNT integrity threats.

3.1.4 Army PNT RA CV-1 Joint Capability Areas (JCAs)

The Joint Capability Area depicted in Figure 2 is as follows.

JCA 6.2.4 PNT: The ability to determine accurate and precise location, orientation, time, and course corrections anywhere in the battle space and to provide timely and assured PNT services across the DoD enterprise.

3.1.5 DoDAF Model Support of Army PNT RA CV-1 Enterprise Goals

Table 5 describes how these DoDAF models support CV-1 Enterprise Goals.

Table 5. DoDAF Model Support of Army PNT RA CV-1 Enterprise Goals

Enterprise Goal Supporting DoDAF Model ID

Supporting Model Element(s)

Detect and Mitigate PNT Integrity Threats

AV-1, AV-2, SV-4 Multiple external and internal sources of PNT feeding the PNT Engine allowing comparison/fusion of inputs

Increase PNT Efficiencies and Eliminate Redundancies

AV-1, AV-2, SV-1, SV-2, SV-4, StdV-1, StdV-2

Distribution capability, standards compliant interfaces, standards compliant data exchanges, and an open systems architecture

UNCLASSIFIED

14

UNCLASSIFIED

Enterprise Goal Supporting DoDAF Model ID

Supporting Model Element(s)

Obtain PNT under EMI Hazard and Threat Conditions

AV-1, AV-2, SV-1, SV-2, SV-4

Anti-Jam Antenna, Pseudo-GPS Satellite, Non-PGS PNT Source

Obtain PNT without GPS AV-1, AV-2, SV-1, SV-2, SV-4

Non-GPS PNT Source

Provide an Affordable Migration Path to M-Code

AV-1, AV-2, SV-1, SV-2, SV-4, StdV-1, StdV-2

Distribution capability, standards compliant interfaces, standards compliant data exchanges, and an open systems architecture

Receive GPS Signals using Military GPS Receivers

AV-1, AV-2, SV-1, SV-2, SV-4

GPS Antenna, GPS Receiver

3.2 Operational Concept for PNT with Assurance

Figure 3 depicts both the capabilities to be provided by the PNT SoS and their employment.

UNCLASSIFIED

15

UNCLASSIFIED

Figure 3. OV-1 High-Level Operational Concept Graphic for PNT with Assurance

UNCLASSIFIED

16

UNCLASSIFIED

The capabilities shown in the Representative Capability Configuration on the right side of the OV-1 address the Army’s vision to provide operational and institutional Army Forces PNT information with assurance under the complete range of threat conditions in an affordable, upgradeable, and adaptable manner. They enable the Army to Stay Ahead of the PNT Threat, Provide an Affordable Migration Path to M-Code, and Increase PNT Efficiencies and Eliminate Redundancies. The PNT SoS provides these capabilities: Obtain PNT Information with Assurance, Facilitate PNT Systems Upgrade/Modification via Open Architectures, and Distribute PNT Information.

As shown in the Representative Capability Configuration, the data needed to Obtain PNT Information with Assurance is accessed from these sources of PNT: GPS Satellite, Pseudo-GPS Satellite, and Non-GPS PNT Source, e.g., an INS or CSAC. The PNT Module receives inputs from external sources, filters out threats, and processes the data with internal source inputs. The PNT Module then determines the integrity of the resulting PNT, represented by the graphic containing "Trust" and "Don't Trust" integrity indicators. This product is PNT Information with Assurance.

The capability to Facilitate PNT Systems Upgrade/Modification via Open Architecture is realized by the PNT Module’s use of a modular, open architecture to help achieve efficiency and eliminate redundancies and unneeded capabilities. The flexibility provided by this open architecture enables the inclusion of only those modules needed to provide PNT Information with Assurance based upon projected mission and operational environment, therefore, reducing initial fielding costs while potentially reducing size, weight, and power (SWaP) requirements. The open architecture potentially also enables the inclusion of new technology, such as an M-Code capability, or improvements to existing capabilities without replacing the entire PNT Module.

The final capability provided is the ability to Distribute PNT Information from the PNT Module to other systems on the platform. In the lower right corner of Figure 3 above, “Representative Capability Configuration”, the green arrows represent network or point-to-point connections to PNT consuming systems, this is illustrated more realistically in the center of Figure 3 above, “Example of PNT Distribution”. Distribution contributes directly to achieving an affordable migration path to M-Code by reducing the number of PNT Modules fielded and, therefore, requiring upgrade for M-Code compatibility or any other reason. It may also reduce SWaP.

The PNT SoS includes the PNT Module, potentially including an Anti-Jam Antenna for point protection, together with the sources of PNT (GPS Satellite, Pseudo-GPS Satellite, and Non-GPS PNT Source) and the distribution capability to the PNT Client Systems. (Note that only a representative implementation is depicted as the potential configurations of the PNT SoS are too numerous to include in a single diagram.)

Configurations of PNT systems, which are employed in all echelons of the Army, will vary based upon PNT risks in the operating environment and the uses to which PNT Information will be put. (Note that Pseudo-GPS Satellites provide area coverage and provide Pseudo-GPS Satellite Information to multiple PNT Modules.)

UNCLASSIFIED

17

UNCLASSIFIED

4. Architecture Patterns

Architecture patterns describe how systems interface, including the standards across interfaces and the types of interfaces that are useable. The architecture patterns for providing and consuming PNT Information are depicted in the high level systems interface patterns below.

4.1 Capability Configuration and Structural Rules

Before describing the PNT RA interface and data flow patterns, it is helpful to discuss two PNT RA elements: the Capability Configuration and its structural rules. The Capability Configuration is a logical construct that includes the systems necessary to provide PNT Information with Assurance to one or more included PNT Client Systems. The structural rules define acceptable combinations of systems in a Capability Configuration while the implementation guidance determines which combination is needed. Other PNT RA system view models describe the interfaces between systems.

4.1.1 Capability Configuration Description

The PNT RA systems included in the Capability Configuration and used throughout this document are described in Table 6.

Table 6. Army PNT RA Systems

System Description

Anti-Jam Antenna A GPS Antenna that has the capability to mitigate jamming signals to aid in receiving GPS signals.

GPS Antenna A generalized component that represents either a Standard Antenna (no anti-jam capabilities) or an Anti-Jam Antenna.

GPS Receiver System or asset that receives signals from GPS Satellites or Pseudo-GPS Satellites and uses the transmitted data to calculate a three-dimensional position and time. (GPS.gov)

GPS Receiver Assembly

A logical construct consisting of a GPS Receiver and a GPS Antenna.

GPS Satellite DoD-owned, space-based system or asset that securely transmits the data necessary for a GPS Receiver to calculate a three-dimensional position and time.

Non-GPS PNT Source

Source of PNT information provided to the PNT Module that is not provided by a GPS satellite. e.g., INS, CSAC and Network Assisted PNT.

PNT Client System A system or asset that consumes PNT Information (e.g., JBC-P or a Network Time Protocol [NTP] server).

PNT Engine A component that processes PNT Information to produce PNT Information with Assurance.

PNT Module A logical construct whose components originate, receive, and/or process data from sources of PNT (e.g., GPS signals) to produce PNT Information with Assurance and that supports, directly and/or via additional communications capabilities, its distribution to one or more PNT Client Systems. Because this is a logical construct, the components may not all be in a single physical enclosure.

Capability Configuration

A logical construct that includes the systems necessary to provide PNT Information with Assurance to one or more included PNT Client Systems.

Pseudo-GPS Satellite

Terrestrial or aerial-based system or asset that securely transmits the data necessary for a GPS Receiver to calculate a three-dimensional position and time.

Standard Antenna A non-anti-jam GPS Antenna.

UNCLASSIFIED

18

UNCLASSIFIED

Figure 4 depicts the Capability Configuration and GPS Antenna generalization. The Capability Configuration’s components and relationships, together with its structural rules, provides a rigorous definition of a Capability Configuration.

Figure 4. Army PNT RA SV-1 Capability Configuration Diagram

4.1.2 Capability Configuration Structural Rules

The relationships among the systems that make up an acceptable Capability Configuration are described by the structural rules in Table 7. These Capability Configuration Structural Rules enable the Army to Stay Ahead of the PNT Threat, Provide an Affordable Migration Path to M-Code, and Increase PNT Efficiencies and Eliminate Redundancies. They take into account the multiplicities and required combinations of systems. For example, all the component systems of the PNT Module appear to be optional, but that is not the case. The permissible components in a PNT Module are, in fact, specified by the structural rules.

UNCLASSIFIED

19

UNCLASSIFIED

Table 7. Structural Rules

# System Rule Rationale

1 Capability Configuration

A Capability Configuration may include GPS Satellites. The PNT RA does not limit the number of GPS Satellites that may be included.

GPS Satellites do not have to be included in all Capability Configurations.

2 Capability Configuration

A Capability Configuration may include Pseudo-GPS Satellites. The PNT RA does not limit the number of Pseudo-GPS Satellites that may be included.

Pseudo-GPS Satellites do not have to be included in all Capability Configurations.

3 Capability Configuration

A Capability Configuration normally includes only one PNT Module. The allowed exceptions are if the PNT Client System requires PNT Information with Assurance for multiple points; or multiple sources of PNT Information with Assurance for a single point; or a mixture of the two.

Multiple PNT Modules may be required to provide high availability PNT Information with Assurance or PNT Information with Assurance for multiple points.

4 Capability Configuration

A Capability Configuration must include one or more PNT Client Systems and those PNT Client Systems must only be included in that Capability Configuration.

One or more PNT Client Systems are required to demonstrate architecture compliance at the interface level. A PNT Client System cannot be part of more than one Capability Configuration because it would be receiving PNT Information with Assurance from two sources. Which source's data does it use?

5 PNT Module A PNT Module must include a GPS Receiver Assembly if, and only if, either a GPS Satellite or a Pseudo-GPS Satellite or both are included in the Capability Configuration.

A GPS Receiver Assembly is required in the PNT Module only if a GPS Satellite or Pseudo-GPS Satellite is included. Conversely, a GPS Satellite or Pseudo-GPS Satellite or both are required only if a GPS Receiver Assembly is included. Otherwise none of these components may be included.

6 PNT Module If a PNT Module includes a GPS Receiver Assembly, then it may include multiple GPS Receiver Assemblies.

Aerostats require PNT for multiple positions on the platform in order to calculate platform yaw, pitch, and roll vectors with and without motion. Similarly, Differential GPS requires two GPS Antennas and GPS Receivers to function.

7 PNT Module A PNT Module must include at least one source of PNT.

A PNT Module requires at least one source of PNT to produce PNT Information with Assurance.

8 PNT Module A PNT Module must include a PNT Engine if no other PNT Module component can process PNT Information to produce PNT Information with Assurance.

A PNT Engine or its functionality is required to process the PNT Information provided by the GPS Receivers and the Non-GPS PNT Sources and to produce PNT Information with Assurance.

UNCLASSIFIED

20

UNCLASSIFIED

# System Rule Rationale

9 PNT Module The PNT Module must be able to distribute PNT Information with Assurance.

Principle PNT-03, Increase PNT efficiencies and eliminate redundancies, requires a distribution capability.

10 GPS Receiver Assembly

A GPS Receiver Assembly must include one GPS Receiver.

A GPS Receiver is required in a GPS Receiver Assembly.

11 GPS Receiver Assembly

A GPS Receiver Assembly must include one GPS Antenna.

A GPS Antenna is required in a GPS Receiver Assembly.

12 GPS Antenna

A GPS Antenna may be shared by multiple GPS Receiver Assemblies, possibly in multiple security domains. However, designers cannot assume that an Anti-Jam Antenna can be shared by multiple security domains.

A GPS Antenna may feed multiple GPS Receivers. However, an Anti-Jam Antenna may be configurable and, therefore, may not be shareable by two GPS Receivers that cannot coordinate commands.

4.2 Systems Interface Patterns

This section describes the general structural and interface patterns of the PNT RA. The PNT systems and interfaces needed to provide PNT Information with Assurance for a particular solution architecture are based on the implementation guidance. In all cases, the resulting Capability Configuration complies with the structural rules.

4.2.1 Systems Interface Description

Figure 5 describes the general structural and interface pattern of a Capability Configuration. The systems drawn with dashed lines are shareable: GPS Satellites and Pseudo-GPS Satellites may be used by multiple Capability Configurations at the same time, and a platform’s GPS Antenna may be shared by multiple GPS Receiver Assemblies.

UNCLASSIFIED

21

UNCLASSIFIED

Figure 5. Army PNT RA SV-1 Systems Interface Description

4.2.1.1 Army PNT RA SV-1 Systems Interface Description System Descriptions

The systems depicted in Figure 5 are described in Table 6.

4.2.1.2 Army PNT RA SV-1 Systems Interface Description Interface Rules

The rules governing the inclusion of the interfaces depicted in Figure 5 are described in Table 8. The PNT RA does not include rules governing the interfaces between the PNT Module and the GPS Satellites and Pseudo-GPS Satellites. (Note: The Army PNT RA SV-1 Systems Interface Description Interface Rules are one segment of the Army PNT RA SV-10a Systems Rules Model.)

Table 8. Army PNT RA SV-1 Systems Interface Description Interface Rules

# System Rule Rationale

1 PNT Module

Each PNT Module must be connected to at least one PNT Client System.

At least a dummy/test PNT Client System is needed for design and test.

UNCLASSIFIED

22

UNCLASSIFIED

# System Rule Rationale

2 PNT Module

Each PNT Module may be connected to multiple different PNT Client Systems.

Ideally, distribution is in use and there are several PNT Client Systems.

3 PNT Client System

Each PNT Client System must be connected to at least one PNT Module.

The PNT Client System must get PNT Information with Assurance from a PNT Module so it must be connected to at least one PNT Module.

4 PNT Client System

Each PNT Client System may be connected to multiple different PNT Modules if it requires PNT Information with Assurance for multiple points, multiple sources of PNT Information with Assurance for a single point, or a mixture of the two.

A PNT Client System may be connected to multiple PNT Modules to obtain high availability PNT Information with Assurance or PNT Information with Assurance for multiple points.

4.2.1.3 Army PNT RA SV-1 Systems Interface Description Resource Descriptions

The resources depicted in Figure 5 are:

GPS Satellite Information: Information sent from the GPS Satellite constellation that provides a GPS Receiver with the ability to determine current position, velocity, and time.

PNT Information with Assurance: Trustworthy PNT Information that has been developed via access to one or more independent sources, depending upon PNT threat conditions.

Pseudo-GPS Satellite Information: Information sent from a Pseudo-GPS Satellite that provides a GPS Receiver with the ability to determine current position, velocity, and time.

Figure 6 depicts the pattern of the resources being exchanged by the systems depicted in Figure 5. The systems and interfaces needed to provide PNT Information with Assurance for a particular solution architecture vary based upon its projected operational environment and the implementation guidance.

UNCLASSIFIED

23

UNCLASSIFIED

Figure 6. Army PNT RA SV-2 Systems Resource Flow Description

4.2.2 Army PNT RA SV-2 Systems Resource Flow Description Port Descriptions

The ports depicted in Figure 6 are:

Antenna: An electrical device that converts electric power into radio waves and vice versa. Some antennas can mitigate jamming and are called Anti-Jam Antennas.

Embedded: System specific connection where the two systems are provided as one unit.

Ethernet Connector: A physical connector used to connect the system to an Ethernet network. A specific connector type and media are purposely not specified to provide flexibility in choice of media.

ISW Antenna: Antenna that uses Ultra-Wideband, encrypted RF interface for secure data exchange at short range.

TIA/EIA-422-B Port: Serial connector compatible with TIA/EIA-422-B.

UNCLASSIFIED

24

UNCLASSIFIED

TIA-232-F Port: Serial connector compatible with TIA-232-F.

USB Port: Universal Serial Bus (USB) connector as described by the USB Implementers Forum.

The ports in Figure 6 are subject to the rules described in Table 9. (Note: The Army PNT RA SV-2 Systems Resource Flow Description Port Rules are one segment of the Army PNT RA SV-10a Systems Rules Model.)

Table 9. Army PNT RA SV-2 Systems Resource Flow Description Port Rules

# System Rule Rationale

1 PNT Module A PNT Module may only include an Antenna Port if it includes a GPS Receiver Assembly.

An Antenna Port is needed only if there is a GPS Receiver.

2 PNT Module A PNT Module must include at least one of the following types of port: USB Port, TIA-232-F Port, TIA/EIA-422-B Port, ISW Antenna, Embedded, and Ethernet Connector. The PNT Module may include multiple instances of each type of port except ISW Antenna.

The PNT Module must be able to distribute PNT Information with Assurance. Therefore, at least one port is required. The number and types of ports included are design dependent and are not limited by the PNT RA.

3 PNT Client System

A PNT Client System must include at least one of the following types of ports: USB Port, TIA-232-F Port, TIA/EIA-422-B Port, ISW antenna, Embedded, and Ethernet Connector. The PNT Client System may include multiple instances of each type of port except ISW antenna.

The PNT Client System must be able to receive PNT Information with Assurance from the PNT Module. The number and types of ports included on the PNT Client System are dependent upon the PNT Module(s) used and are not limited by the PNT RA.

4.2.3 Army PNT RA SV-2 Systems Resource Flow Description Information Exchange Standards

The standards depicted in Figure 6 are listed below.

ICD-GPS-203D, IRN 003: NAVSTAR GPS SA/AS Requirements, 25 Jan 2012 (S)

ICD-GPS-700B, IRN 002: NAVSTAR GPS Military-Unique Space Segment/User Segment Interfaces, 21 Jul 2011

IS‐GPS‐705A: NAVSTAR GPS Space Segment / User Segment L5 Interfaces, 8 Jun 2010

IS-GPS-153D: GPS User Equipment Interface Specification for the GPS Standard Serial Interface Protocol (GSSIP) of DoD Standard GPS UE Radio Receivers, 23 Jul 2007

IS-GPS-200H: NAVSTAR GPS Space Segment/Navigation User Interfaces, 31 Jan 2013

IS-GPS-250A: Global Positioning Systems (GPS) P(Y)-Code External Augmentation System (EAS) I User Equipment Interface, 30 Jan 2012 (This standard will be replaced by a revision, IS-GPS-250B, when it is approved.)

IS-GPS-703C: NAVSTAR GPS Military-Unique Space Segment/User Segment Interfaces (Classified Requirements) (S)

IS-GPS-726, IRN 002: NAVSTAR GPS Military-Unique Pseudolite/User Equipment Interface, 16 May 2007 (under revision)

MSID-001A: Military GPS User Equipment (MGUE) Serial Interface Document, MSID-001A 13 Feb 2015

UNCLASSIFIED

25

UNCLASSIFIED

VICTORY Standard: Vehicular Integration for C4ISR/EW Interoperability (VICTORY) Standard Specification 1.6.2, 31 Mar 2015 or latest at: https://portal.victory-standards.org/SitePages/Home.aspx

4.2.4 Army PNT RA SV-2 Systems Resource Flow Description Port Related Standards

To make the SV-2 graphic less cluttered, two ports were labeled with multiple standards instead of showing multiple ports with a single standard. The label on these ports begins with “USB Port” in Figure 6. An actual implementation of these ports would conform to only one of the standards. The standards applicable to all ports depicted are:

Embedded: This type of port does not have a standard due to the variability of implementations.

Ethernet Connector IEEE 802.3-2012: IEEE Standard for Ethernet, 28 December 2012

Wireless LAN IEEE 802.11-2016: IEEE Standard for Wireless LAN Medium Access Control (MAC) and Physical Layer, December 2016

ISW Antenna: The Secure Intra-Soldier Wireless Standard Specification which is under development

TIA/EIA-422-B Port TIA/EIA-422-B: Electrical Characteristics of Balanced Voltage Digital Interface Circuits, May 1994

TIA-232-F Port TIA-232-F: Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange

USB Port USB: Revision 3.1 Specification; USB 2 or better is generally acceptable

4.2.5 Army PNT RA SV-2 Systems Resource Flow Description Interface-Standards Mapping

Table 10 summarizes and augments the mapping of standards to interfaces depicted in Figure 6.

Table 10. Army PNT RA SV-2 Interface-Standards Mapping

# Interface Name Applicable Standards Notes

1 IF GPS-PM ICD-GPS-203D, IRN 003 ICD-GPS-700B, IRN 002 IS-GPS-200H IS-GPS-703C IS-GPS-705A

Interface must comply with these standards.

2 IF P_GPS-PM ICD-GPS-203D, IRN 003 ICD-GPS-700B, IRN 002 IS-GPS-200H IS-GPS-250A IS-GPS-703C IS-GPS-705A IS-GPS-726, IRN 002

Interface must comply with these standards. IS-GPS-726, IRN 002 is an emerging standard. Compliance with it will be required when the Pseudo-GPS Satellite is M-Code capable.

3 IF PM-Client_Direct IS-GPS-153D MSID-001A

Interface must comply with IS-GPS-153D. MSID-001A is an emerging standard. Compliance with it will be required when the PNT Module is M-Code capable.

UNCLASSIFIED

26

UNCLASSIFIED

# Interface Name Applicable Standards Notes

4 IF PM-Client_Ntwk VICTORY Standard Interface must comply with this standard. The network interface is the preferred/objective method of distribution.

The rules governing the inclusion of the interfaces depicted in Figure 6 are described in Table 11. (Note: The Army PNT RA SV-2 Systems Resource Flow Description Interface Rules are one segment of the Army PNT RA SV-10a Systems Rules Model.)

Table 11. Army PNT RA SV-2 Systems Resource Flow Description Interface Rules

# System Rule Rationale

1 PNT Module, PNT Client System

A given PNT Module and PNT Client System must be connected either by an instance of IF PM-Client_Direct or an instance of IF PM-Client_Ntwk.

A PNT client must have a single connection to the PNT Module.

2 PNT Module A PNT Module may connect to multiple different PNT Client Systems by instances of IF PM-Client_Direct or an instance of IF PM-Client_Ntwk.

A PNT Module can distribute PNT Information with Assurance to multiple different PNT Client Systems.

3 PNT Client System

A PNT Client System may connect to multiple different PNT Modules by instances of IF PM-Client_Direct or an instance of IF PM-Client_Ntwk.

A PNT Client System may need to connect to multiple PNT Modules to obtain high availability PNT Information with Assurance or PNT Information with Assurance for multiple points.

4.3 System Function Pattern

Figure 7 depicts the pattern of notional PNT related system functions performed by the systems depicted in Figure 5. The term notional is used because the Army PNT RA simply describes high level functionality that systems must provide, rather than specifying how the system must provide that functionality. (Note that all details and interactions of PNT Module components are not included and that Figure 7 is descriptive, not prescriptive and does not rule out additional system functions or data flows between them.)

UNCLASSIFIED

27

UNCLASSIFIED

Figure 7. Army PNT RA SV-4 Systems Functionality Flow Description

The SV-4 contains swim lanes, system functions, and resource flows (i.e., data flows) between functions. The swim lanes represent the GPS Satellite, Pseudo-GPS Satellite, PNT Module and its included systems, and the PNT Client System. Each swim lane contains the system functions performed by the corresponding system. Finally, the data flows represent system function interactions.

4.3.1 Army PNT RA SV-4 Systems Functionality Flow Description System Function Descriptions

The system functions depicted in Figure 7 are described below with existing Joint Common System Function List (JCSFL) equivalent/near equivalent function noted parenthetically.

Distribute PNT Information: A system function that delivers PNT Information with Assurance to PNT Client Systems for their use. (Joint, 2011).

UNCLASSIFIED

28

UNCLASSIFIED

Generate GPS Satellite Information: A system function that generates GPS Satellite Information used by a GPS Receiver to determine current position, velocity, and time.

Generate Non-GPS PNT Information: A system function that generates PNT Information often without use of GPS Satellite Information.

Generate Pseudo-GPS Satellite Information: A system function that generates Pseudo-GPS Satellite Information used by a GPS Receiver to determine current position, velocity, and time.

Process Coarse/Acquisition (C/A) Code: A system function that translates C/A code into understandable PNT Information.

Process GPS Information: A system function that translates GPS Satellite Information and Pseudo-GPS Satellite Information into understandable PNT Information. (Joint, 2011).

Process M-Code: A system function that translates M-Code into understandable PNT Information.

Process PNT Information: A system function that prepares PNT Information with Assurance for use by PNT Client Systems.

Process Precision (P/Y) Code: A system function that translates P(Y) code into understandable PNT Information.

Process Pseudo-GPS Satellite Information: A system function that translates the Pseudo-GPS Satellite Information into usable PNT Information. (Joint, 2011).

Protect Against Jamming: A system function that cancels or reduces jamming signals. (Joint, 2011).

Receive PNT Information: A system function that has been designed to receive PNT information.

Figure 7 represents a scenario in which the PNT related systems, part of a solution architecture, are working properly. Execution in the scenario proceeds as follows, generally flowing from top to bottom.

1. Upon entry, Generate GPS Satellite Information is producing GPS Satellite Information, and Generate Pseudo-GPS Satellite Information is producing Pseudo-GPS Satellite Information.

2. If the GPS Antenna is an Anti-Jam Antenna, it performs Protect Against Jamming by canceling or reducing jamming signal inputs; otherwise, the GPS Satellite Information and Pseudo-GPS Satellite Information flow directly into Process GPS Information. This SV-4 assumes the Anti-Jam Antenna will pass Pseudo-GPS Satellite Information.

3. Process GPS Information requires either GPS Satellite Information or Pseudo-GPS Satellite Information or both to produce an output.

4. Process PNT Information requires either or both PNT Information inputs to potentially produce an output.

5. Distribute PNT Information requires PNT Information with Assurance to distribute. 6. Generate Non-GPS PNT Information often requires PNT Information to begin

producing PNT Information itself. In that case, PNT Information generation begins only after receiving PNT Information from Process PNT Information. It often needs periodic PNT Information input to continue providing a useable output.

7. Finally, the PNT Client System receives PNT Information with Assurance via Receive PNT Information.

4.3.2 Army PNT RA SV-4 Systems Functionality Flow Description Additional Resource Descriptions

Figure 7 introduces an additional resource.

UNCLASSIFIED

29

UNCLASSIFIED

PNT Information: (from the PNT JCD) Information that enables any combination of the following capabilities in a consuming system (see Section 1.5).

4.4 Army PNT RA Architecture Pattern Rules

The Army PNT RA SV-10a Systems Rules Model identifies rules governing the PNT systems included in a Capability Configuration and the interfaces between them. These rules have been introduced with the DoDAF model affected and are not repeated here. The sets of rules are as follows: Table 7, Table 8, Table 9, and Table 11.

4.5 PNT Distribution Pattern

The Army PNT RA supports the implementation of a distribution pattern for PNT Information with Assurance. Establishing a common source for PNT on a platform allows for the reduction in redundant systems. It also helps to achieve the goal of Providing an Affordable Path to M-Code. Moving from multiple PNT Modules to a single PNT Module is demonstrated in Figure 9.

Figure 8. PNT Distribution Pattern

There are two basic distribution pattern implementations: networked (wired or wireless) and point-to-point (wired or wireless). Both are logically equivalent to the PNT Distribution pattern in Figure 8. A networked distribution pattern could consist of a PNT Module connected to a VICTORY Data Bus (VDB) to which PNT Client Systems are also connected. PNT Client Systems would interact with the PNT Module to request PNT Information with Assurance via the VDB and the PNT Module would then send it via the VDB when it is available. The services provided by the PNT Module and the data exchanges would comply with the VICTORY standard. In a point-to-point distribution pattern in which a PNT Module is physically (including wirelessly) connected to PNT Client Systems, similar exchanges would take place, but they would comply with standards for serial communications, such as IS-GPS-153D and MSID-001A. Both distribution patterns would also be governed by applicable network or serial communications standards, respectively. (Note that the PNT Client System may further distribute the PNT Information with Assurance; however, such distribution is beyond the scope of Version 1.0 of the PNT RA.)

In some situations, redundant PNT Modules may also be necessary to provide the required level of operational availability (Ao) on the platform.

UNCLASSIFIED

30

UNCLASSIFIED

5. Technical Position

The DoD Information Technology Standards Registry (DISR) and other standards listed in Table 12 represent the PNT RA's technical position, i.e., technical guidance and standards that need to be implemented as part of a solution architecture. Their use within the PNT RA is outlined in the AV-2 Integrated Dictionary in Appendix D Army PNT RA All Viewpoint Views. (Note: The Army PNT RA SV-2 Systems Resource Flow Description Interface Rules are one segment of the Army PNT RA SV-10a Systems Rules Model.)

Table 12. Army PNT RA StdV-1

Standard Identifier

Standard Title Standard Class

DoD Status

ICD-GPS-203D, IRN 003

NAVSTAR GPS SA/AS Requirements 25 Jan 2012

Non-DISR

IEEE 802.3-2012 IEEE Standard for Ethernet, 28 December 2012 DISR Mandated

IS-GPS-153D GPS User Equipment Interface Specification for the GPS Standard Serial Interface Protocol (GSSIP) of DoD Standard GPS UE Radio Receivers, 23 July 2007

DISR Mandated

IS-GPS-200H NAVSTAR GPS Space Segment/Navigation User Interfaces, 24 September 2013

DISR Mandated

IS-GPS-250A Global Positioning Systems (GPS) P(Y)-Code External Augmentation System (EAS) I User Equipment Interface, 30 Jan 2012

Non-DISR

TIA/EIA-422-B Electrical Characteristics of Balanced Voltage Digital Interface Circuits, May 1994

DISR Retired

TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange (October 1997, Reaffirmed December 2012)

DISR Mandated

USB Universal Serial Bus Revision 3.1 Specification, July 26, 2013; USB 2 or better is generally acceptable.

Non-DISR

VICTORY Standard

Vehicular Integration for C4ISR/EW Interoperability (VICTORY) Standard Specification 1.6.2, 31 March 2015 or latest https://portal.victory-standards.org/SitePages/Home.aspx

Information / Guidance

(I/G) Document

Active

UNCLASSIFIED

31

UNCLASSIFIED

New standards that relate to PNT are emerging. The emerging standards are described in the StdV-2 in Table 13. Their use in the PNT RA, if any, is indicated in the AV-2 Integrated Dictionary in Appendix C.

Table 13. Army PNT RA StdV-2

Standard Identifier

Standard Title Standard Class

DoD Status

ICD-GPS-700B, IRN 002

NAVSTAR GPS Military-Unique Space Segment/User Segment Interfaces, 21 July 2011

Non-DISR Emerging

IS-GPS-250B Global Positioning Systems (GPS) P(Y)-Code External Augmentation System (EAS) I User Equipment Interface, TBD

Non-DISR Emerging

IS-GPS-703C NAVSTAR GPS Military-Unique Space Segment/User Segment Interfaces (Classified Requirements)

Non-DISR Emerging

IS‐GPS‐705A NAVSTAR GPS Space Segment / User Segment L5 Interfaces, 8 June 2010

Non-DISR Emerging

IS-GPS-726, IRN 002

NAVSTAR GPS Military-Unique Pseudolite/User Equipment Interface, 16 May 2007 (under revision)

Non-DISR Emerging

ISW Secure Intra-Soldier Wireless Standard Specification (under development)

Non-DISR Emerging

MSID-001A Military GPS User Equipment (MGUE) Serial Interface Document, MSID-001A 13 Feb 2015

Non-DISR Emerging

UNCLASSIFIED

32

UNCLASSIFIED

Notional Usage of the Army PNT RA

The Army PNT RA is intended to be used in the following fashion. A system or platform needing PNT Information with Assurance first determines the PNT threat in its projected operational environment. System developers would then consult the PNT RA’s implementation guidance to determine which PNT systems (i.e., PNT Module and sources of PNT: GPS Satellite, Pseudo-GPS Satellite and Non-GPS PNT Source) are necessary to meet mission needs and to mitigate risk in accordance with the expected operational environment. The contents of the PNT RA are then used in the design of the PNT portion of the system to ensure PNT Information with Assurance is consumed or provided. System developers would also consider PNT distribution as covered in Section 4.5. The system may need to distribute PNT Information or the system may receive PNT Information from another system that is already distributing it. This example only addresses the PNT RA’s system patterns, interfaces, and standards because the PNT RA does not yet include implementation guidance.

With the list of required PNT systems that results from application of the implementation guidance, and the patterns; interfaces; and standards within the PNT RA, the designers and architects are ready to integrate the necessary PNT systems into their system’s solution architecture. This includes incorporating the required systems into the architecture, connecting them to each other via interfaces identified in the PNT RA’s SV-1 and SV-2 diagrams, ensuring that the interfaces comply with the specified standards as identified in the SV-2, ensuring that PNT system functions align with the functions and systems depicted in the SV-4, and ensuring that the SV-10a rules are followed each step of the way.

Figure 9 shows an example of a solution aligned with the Army PNT RA SV-2. The example illustrates the use of a PNT Module as the source of timing information for an NTP server.

Figure 9. SV-2 Alignment Example

UNCLASSIFIED

33

UNCLASSIFIED

Abbreviations and Acronyms

Acronym/Abbreviation Definition

AAE Army Acquisition Executive

AF Architecture Framework

AIA Army Information Architecture

Ao Operational Availability

ArCADIE Army Capability Architecture Development and Integration Environment

ASA(ALT) Assistant Secretary of the Army for Acquisition, Logistics and Technology

AV All View

C/A Code Coarse/Acquisition Code

C2 Command and Control

C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance

CCJO Capstone Concept for Joint Operations

CDD Capability Development Document

CE Computing Environment

CECOM (United States Army) Communications-Electronics Command

CJCSI Chairman of the Joint Chiefs of Staff Instruction

COE Common Operating Environment

CSAC Chip Scale Atomic Clock

CV Capability View

DA Department of the Army

DISR DoD Information Technology Standards Registry

DoD Department of Defense

DoDAF Department of Defense Architecture Framework

DoD CIO Department of Defense Chief Information Officer

DOTMLPF Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities

DSD Data and Services Deployment

EAS External Augmentation System

EMI Electromagnetic Interference

EP Electronic Protection

EW Electronic Warfare

FAA Functional Area Analysis

GPS Global Positioning System

GSSIP GPS Standard Serial Interface Protocol

HAE Height Above Ellipsoid

I/G Information / Guidance

ICD Initial Capabilities Document

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

INS Inertial Navigation System

ISW Intra-Soldier Wireless

JBC-P Joint Battle Command-Platform

JCA Joint Capability Area

JCD Joint Capabilities Document

JCSFL Joint Common System Function List

JP Joint Publication

JWCR An Evolving Joint Perspective: US Joint Warfare and Crisis Resolution In the 21st Century

M-Code Military Code

MGUE Military GPS User Equipment

MOD Ministry of Defence

UNCLASSIFIED

34

UNCLASSIFIED

Acronym/Abbreviation Definition

MODAF UK Ministry of Defence (MOD) Architecture Framework (MODAF)

MPNTP Master Positioning, Navigation, and Timing Plan

MSID Military GPS User Equipment (MGUE) Serial Interface Document

NAVWAR Navigation Warfare

NTP Network Time Protocol

OASD/NII Office of the Assistant Secretary of Defense, Networks and Information Integration

OMG Object Management Group

OSA Open Systems Architecture

OUSD AT&L Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics

OV Operational View

P(Y) Code P-Code and Y-Code

PNT Positioning, Navigation and Timing

SoSA System of Systems Architecture

PRN Pseudo Random Noise (pseudorandom binary sequence)

RA Reference Architecture

RF Radio Frequency

SAASM Selective Availability Anti-Spoof Module

SoS System of Systems

SoSA System of Systems Architecture

StdV Standards View

SoSE&I System of Systems Engineering & Integration (Directorate)

SV Systems View

SWaP Size, Weight, and Power

SysML OMG Systems Modelling Language ™

TCM TRADOC Capability Manager

TR Tactical Radios

TRADOC U.S. Army Training and Doctrine Command

UK United Kingdom

UPDM Unified Profile for the Department of Defense (DoD) Architecture Framework (AF) (DoDAF) and the Ministry of Defence (MOD) AF (MODAF)

USB Universal Serial Bus

USD (AT&L) Under Secretary of Defense for Acquisition, Technology, and Logistics

USNO U.S. Naval Observatory

UTC Coordinated Universal Time

VDB VICTORY Data Bus

VICTORY Vehicular Integration for C4ISR/EW Interoperability

WGS 84 World Geodetic System 1984

UNCLASSIFIED

35

UNCLASSIFIED

Glossary of Terms

Term Description

Access Access is obtaining source data to generate PNT Information.

Architecture The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment and the principles guiding its design and evolution (IEEE, 2000)

Army Acquisition Executive (AAE)

The AAE solely is responsible for acquisition matters within the Department of the Army (DA) and is the single decision authority for all Army acquisition matters. The AAE is responsible for approving all requests to initiate new acquisition programs and will do so only when they are supported by approved capability documents, requisite funding, and program documentation. (http://www.apd.army.mil/jw2/xmldemo/r70_1/main.asp)

Army PNT RA The architecture contained in this document.

AV-1 Overview & Summary Information

A DoDAF V2.0 Model which describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects.

AV-2 Integrated Dictionary

A DoDAF V2.0 Model which is an architectural data repository with definitions of all terms used throughout the architectural data and presentations.

Computing Environment (CE)

The COE (Common Operating Environment) is an approved set of computing technologies and standards that enable secure and interoperable applications to be developed and executed rapidly across a variety of computing environments (i.e., server(s), client, mobile, sensors and platform). Each computing environment has a minimum standard configuration that supports the Army‘s ability to produce and deploy quickly high-quality applications, and to reduce the complexities of configuration, support, and training associated with the computing environment. (http://ciog6.army.mil/Portals/1/To-Be-Architecture/Appendix C - Common Operating Environment Architecture signed Oct 2010.pdf)

CV-1 Vision A DoDAF V2.0 Model presents the overall vision for transformational endeavors and provides a strategic context for the capabilities described and a high-level scope.

Full Design Disclosure

Full design disclosure describes a continuum of data and software deliverables ranging from Form, Fit, and Function data to detailed manufacturing and process data or source code.

Implementation Guidance

To be provided in Version 2.0 of the PNT RA. It will guide the implementation of systems to help ensure that they consume or provide PNT Information with Assurance when operating in their target PNT threat conditions.

Integrity Integrity, in the context of the PNT RA, is the trustworthiness of PNT Information.

Milestone Decision Authority

The individual designated in accordance with criteria established by the USD (AT&L) or by the DoD CIO for acquisition programs, to approve entry of an acquisition program into the next phase. (Chairman, 2013)

Open System Architectures

An open architecture is a technical architecture that adopts open standards supporting a modular, loosely coupled, and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure. A key enabler for open architecture is the adoption of an open business model, which requires doing business transparently to leverage the collaborative innovation of numerous participants across the enterprise permitting shared risk, maximize asset reuse, and reduce total ownership costs. The combination of open architecture and an open business model permits the acquisition of Open Systems Architectures that yield modular, interoperable systems allowing components to be added, modified, replaced, removed, and/or supported by different vendors throughout the life cycle to drive opportunities for enhanced competition and innovation (DoD, 2013).

UNCLASSIFIED

36

UNCLASSIFIED

Term Description

OV-1 High-Level Operational Concept Graphic

A DoDAF V2.0 Model which presents a high-level graphical/textual description of the operational concept.

PNT Condition Levels

Gradations representing PNT conditions (i.e., threat and environment) in which Army Forces may be required to operate. Condition levels are developed via gross quantization of the probability of loss of PNT Information with Assurance.

Positioning, Navigation and Timing (PNT)

PNT stands for positioning, navigation, and timing where positioning is the ability to determine accurate and precise locations (and velocity), navigation is the ability to maneuver with accuracy and precision, and timing is the ability to acquire and maintain accurate and precise time. (https://www.pmpnt.army.mil/get-support/faq/)

Product Owners Those personnel, including organizations, which have a valued solution architecture that may or may not have been realized into a material solution through a formal acquisition pursuit.

Pseudolite A Pseudo-GPS Satellite that provides terrestrial radio navigation (GPS-like) service in electronically or physically challenged environments using a high power signal.

Reference Architecture

[…]The primary purpose of a Reference Architecture is to guide and constrain the instantiations of solution architectures[…]Reference Architecture is considered an organizational asset in:

Providing common language for the various stakeholders

Providing consistency of implementation of technology to solve problems

Supporting the validation of solutions against proven Reference Architectures

Encouraging adherence to common standards, specifications, and patterns (CIO, 2010).

Solution Architecture

The DoDAF defines Solution Architecture as a framework or structure that portrays the relationships among all the elements of something that answers a problem. It describes the fundamental organization of a system, embodied in its components, their relationships with each other and the environment, and the principles governing its design and evolution. Solution architecture instantiations are guided and constrained by all or part of a Reference Architecture where the generalized and logical abstract elements of the Reference Architecture are replaced by real world, physical elements according to the specified rules, principles, standards and specifications (CIO, 2010).

Sources of PNT Sources of PNT are devices, systems, or sensors, internal or external to the PNT Module, that provide information enabling the determination of current position, velocity, and time.

Space Segment The Space Segment consists of a nominal constellation of operating satellites that transmit one-way signals that give the current GPS Satellite position and time.

StdV-1 Standards Profile

A DoDAF V2.0 Model that consists of a listing of standards that apply to solution elements of the architecture.

StdV-2 Standards Forecast

A DoDAF V2.0 Model that consists of a description of emerging standards and potential impact on current solution elements, within a set of time frames.

SV-1 Systems Interface Description

A DoDAF V2.0 Model that includes the identification of systems, system items, and their interconnections.

SV-10a Systems Rules Model

One of three DoDAF V2.0 Models used to describe system functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.

SV-2 Systems Resource Flow Description

A DoDAF V2.0 Model that includes the description of Resource Flows exchanged between systems.

UNCLASSIFIED

37

UNCLASSIFIED

Term Description

SV-4 Systems Functionality Description

A DoDAF V2.0 Model which includes the functions (activities) performed by systems and the system data flows among system functions (activities).

System A functionally-, physically-, and/or behaviorally-related group of regularly interacting or interdependent elements; that group of elements forms a unified whole (Joint, 2017).

System Architecture Pattern

The system architecture pattern is defined as a high-level structure, appropriate to the design of the major components of a system, expressing the relation between the context, a problem, and a solution, documenting attributes, and usage guidance (Systems, 2010).

System of Systems (SoS)

A set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities (Office, 2013).

System of Systems Architecture

An architecture is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE, 2000; DoDAF). The architecture of a SoS is a persistent technical framework for governing the evolution of a SoS over time. (Office, 2013)

User Segment The user segment consists of the GPS Receiver equipment, which receives the signals from the GPS Satellites and uses the transmitted information to calculate the user’s three-dimensional position and time.

UNCLASSIFIED

38

UNCLASSIFIED

Army PNT RA All Viewpoint Views

Army PNT RA All Viewpoint Models

AV-1: Overview and Summary Information

The AV-1 information can be found in Section 1, which includes the purpose, contents, applicability, scope, overview, and stakeholders, Section 3.1, which contains the Army vision for PNT with Assurance, and Section 2.2, which includes constraints and assumptions.

AV-2: Integrated Dictionary

Table 14 is the AV-2 Integrated Dictionary for the architecture.

Table 14. Army PNT RA AV-2

Name Description Type Use

Antenna An electrical device that converts electric power into radio waves and vice versa. Some antennas can mitigate jamming (Anti-Jam Antennas).

Port SV-2

Anti-Jam Antenna A GPS Antenna that has the capability to mitigate jamming signals to aid in receiving GPS signals.

System SV-1

Capability Configuration

A logical construct that includes the systems necessary to provide PNT Information with Assurance to one or more included PNT Client Systems.

System SV-1, SV-2

Capability Configuration Structural Rule 01

A Capability Configuration may optionally include GPS Satellites. The PNT RA does not limit the number of GPS Satellites that may be included.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 02

A Capability Configuration may optionally include Pseudo-GPS Satellites. The PNT RA does not limit the number of Pseudo-GPS Satellites that may be included.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 03

A Capability Configuration normally includes only one PNT Module. The allowed exceptions are if the PNT Client System requires PNT Information with Assurance for multiple points, multiple sources of PNT Information with Assurance for a single point, or a mixture of the two.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 04

A Capability Configuration must include one or more PNT Client Systems and those PNT Client Systems must only be included in that Capability Configuration.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 05

A PNT Module must include a GPS Receiver Assembly if, and only if, either a GPS Satellite or a Pseudo-GPS Satellite or both are included in the Capability Configuration.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 06

If a PNT Module may include a GPS Receiver Assembly, then it may include multiple GPS Receiver Assemblies.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 07

A PNT Module must include at least one source of PNT.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 08

A PNT Module must include a PNT Engine if no other PNT Module component can process PNT Information to produce PNT Information with Assurance.

Structural Rule

SV-1, SV-2, SV-10a

UNCLASSIFIED

39

UNCLASSIFIED

Name Description Type Use

Capability Configuration Structural Rule 09

The PNT Module must be able to distribute PNT Information with Assurance.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 10

A GPS Receiver Assembly must include one GPS Receiver.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 11

A GPS Receiver Assembly must include one GPS Antenna.

Structural Rule

SV-1, SV-2, SV-10a

Capability Configuration Structural Rule 12

A GPS Antenna may be shared by multiple GPS Receiver Assemblies, possibly in multiple security domains. However, designers cannot assume that an Anti-Jam Antenna can be shared by multiple security domains.

Structural Rule

SV-1, SV-2, SV-10a

Coarse/Acquisition (C/A) Code

The C/A-code consists of a 1023 bit pseudorandom noise (PRN) code with a clock rate of 1.023 MHz which repeats every 1 millisecond. The short length of the C/A-code sequence is designed to enable a receiver to rapidly acquire the satellite signals that helps the receiver transition to the longer P-code. A different PRN is assigned to each GPS Satellite and selected from a set of codes called Gold codes. The Gold codes are designed to minimize the probability that a receiver will mistake one code for another (minimize the cross-correlation). The C/A-code is transmitted only on L1. The C/A-code is not encrypted and is therefore available to all users of GPS (NAVSTAR, 1996).

Definition N/A

Detect and Mitigate PNT Integrity Threats

This goal is focused on the need to detect and mitigate GPS signal spoofing or other threats to PNT integrity.

Enterprise Goal

CV-1

Distribute PNT Information

The ability to distribute PNT Information to local systems that need it, e.g., on a platform.

Capability CV-1

Distribute PNT Information

A system function that delivers PNT Information with Assurance to PNT Client Systems for their use. (Joint, 2011).

System Function

SV-4

Embedded System specific connection where the two systems are provided as one unit.

Port SV-2

Ethernet Connector

A physical connector used to connect the system to an Ethernet network. A specific connector type and media are purposely not specified to provide flexibility in choice of media.

Port SV-2

UNCLASSIFIED

40

UNCLASSIFIED

Name Description Type Use

Facilitate PNT Systems Upgrade / Modification via Open Architectures

The use of open architectures facilitates upgrades and modifications. An open architecture is a technical architecture that adopts open standards supporting a modular, loosely coupled and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure. A key enabler for open architecture is the adoption of an open business model, which requires doing business transparently to leverage the collaborative innovation of numerous participants across the enterprise permitting shared risk, maximize asset reuse and reduce total ownership costs. The combination of open architecture and an open business model permits the acquisition of open systems architectures (OSAs) that yield modular, interoperable systems allowing components to be added, modified, replaced, removed and/or supported by different vendors throughout the life cycle in order to drive opportunities for enhanced competition and innovation (DoD, 2013).

Capability CV-1

Generate GPS Satellite Information

A system function that generates GPS Satellite Information used by a GPS Receiver to determine current position, velocity, and time.

System Function

SV-4

Generate Non-GPS PNT Information

A system function that generates PNT Information often without use of GPS Satellite Information.

System Function

SV-4

Generate Pseudo-GPS Satellite Information

A system function that generates Pseudo-GPS Satellite Information used by a GPS Receiver to determine current position, velocity, and time.

System Function

SV-4

GPS Antenna A generalized component that represents either a Standard Antenna (no anti-jam capabilities) or an Anti-Jam Antenna.

System SV-1, SV-2

GPS Receiver System or asset that receives signals from GPS Satellites or Pseudo-GPS Satellites and uses the transmitted data to calculate a three-dimensional position and time. (GPS.gov)

System SV-1, SV-2

GPS Receiver Assembly

A logical construct consisting of a GPS Receiver and a GPS Antenna.

System SV-1, SV-2

GPS Satellite DoD-owned, space-based system or asset that securely transmits the data necessary for a GPS Receiver to calculate a three-dimensional position and time.

System SV-1, SV-2, SV-4

GPS Satellite Information

Information sent from the GPS Satellite constellation that provides a GPS Receiver with the ability to determine current position, velocity, and time.

Exchange Element

SV-1, SV-2, SV-4

ICD-GPS-203D, IRN 003

NAVSTAR GPS SA/AS Requirements, 25 Jan 2012 (S)

Standard StdV-1, SV-2

ICD-GPS-700B, IRN 002

NAVSTAR GPS Military-Unique Space Segment/User Segment Interfaces, 21 July 2011

Standard StdV-2, SV-2

IEEE 802.3-2012 IEEE Standard for Ethernet, 28 December 2012 Standard StdV-1, SV-2

IF GPS-PM Interface between the GPS Satellite and the PNT Module.

Interface SV-2

UNCLASSIFIED

41

UNCLASSIFIED

Name Description Type Use

IF P_GPS-PM Interface between the Pseudo-GPS Satellite and the PNT Module.

Interface SV-2

IF PM-Client_Direct

Direct point to point interface between the PNT Module and the PNT Client System.

Interface SV-2

IF PM-Client_Ntwk Network interface between the PNT Module and the PNT Client System.

Interface SV-2

Increase PNT Efficiencies and Eliminate Redundancies

This goal is focused on reducing the number of PNT Modules via platform distribution of PNT- providing the platform with a source of PNT that is then distributed to each of the client systems requiring PNT data. This will provide cost savings and allow enhancement of the single PNT Module’s capabilities that would likely not be possible technically and financially if multiple systems had to be updated. (Coggins, 2015)

Enterprise Goal

CV-1

IS-GPS-153D GPS User Equipment Interface Specification for the GPS Standard Serial Interface Protocol (GSSIP) of DoD Standard GPS UE Radio Receivers, 23 July 2007

Standard StdV-1, SV-2

IS-GPS-200H NAVSTAR GPS Space Segment/Navigation User Interfaces, 31 Jan 2013

Standard StdV-1, SV-2

IS-GPS-250A GPS P(Y)-Code External Augmentation System (EAS) I User Equipment Interface, 30 Jan 2012

Standard StdV-1, SV-2

IS-GPS-250B GPS P(Y)-Code External Augmentation System (EAS) I User Equipment Interface, TBD

Standard StdV-2, SV-2

IS-GPS-703C NAVSTAR GPS Military-Unique Space Segment/User Segment Interfaces (Classified Requirements) (S)

Standard StdV-2, SV-2

IS‐GPS‐705A NAVSTAR GPS Space Segment / User Segment L5 Interfaces, 8 June 2010

Standard StdV-2, SV-2

IS-GPS-726, IRN 002

NAVSTAR GPS Military-Unique Pseudolite/User Equipment Interface, 16 May 2007 (under revision)

Standard StdV-2, SV-2

ISW Secure Intra-Soldier Wireless Standard Specification (under development).

Standard StdV-2, SV-2

ISW Antenna Antenna that uses Ultra-Wideband, encrypted RF interface for secure data exchange at short range.

Port SV-2

JCA 6.2.4 Position, Navigation and Timing

The ability to determine accurate and precise location, orientation, time, and course corrections anywhere in the battle space and to provide timely and assured PNT services across the DoD enterprise.

Capability CV-1

M-Code An enhanced GPS signal that provides improved anti-jam and security protection and will allow users easier access to encrypted coding and spectral separation from civil (unencrypted) signals.

Definition N/A

MSID-001A Military GPS User Equipment (MGUE) Serial Interface Document, MSI-001A 13 Feb 2015

Standard StdV-2, SV-2

Non-GPS PNT Source

Source of PNT information provided to the PNT Module that is not provided by a GPS satellite, e.g., INS, CSAC and Network Assisted PNT.

System SV-1, SV-2

UNCLASSIFIED

42

UNCLASSIFIED

Name Description Type Use

Obtain PNT Information with Assurance

Ability to obtain trustworthy PNT Information that has been developed via access to one or more independent sources, depending upon PNT threat conditions. This includes receiving GPS signals using military GPS Receivers, obtaining PNT under EMI hazard and threat conditions, obtaining PNT without GPS, and detecting and mitigating PNT integrity threats.

Capability CV-1

Obtain PNT under EMI Hazard and Threat Conditions

This goal is focused on the need to receive GPS signals or otherwise obtain PNT under EMI hazards and threats.

Enterprise Goal

CV-1

Obtain PNT without GPS

This goal is focused on the need to obtain PNT in complex terrain, such as dense vegetation, built-up urban and mountainous terrain, or when there simply is no GPS signal available.

Enterprise Goal

CV-1

PNT Client System A system or asset that consumes PNT Information (e.g., JBC-P or NTP server).

System SV-1, SV-2, SV-4

PNT Engine A component that processes PNT Information to produce PNT Information with Assurance.

System SV-1, SV-2

PNT Information From the PNT JCD: Information that enables any combination of the following capabilities in a consuming system (see Section 1.5)

Exchange Element

SV-4

PNT Information with Assurance

Trustworthy PNT Information that has been developed via access to one or more independent sources, depending upon PNT threat conditions.

Exchange Element

SV-2, SV-4

PNT Module A logical construct whose components originate, receive, and/or process data from sources of PNT (e.g., GPS signals) to produce PNT Information with Assurance and that supports, directly and/or via additional communications capabilities, its distribution to one or more PNT Client Systems. Because this is a logical construct, the components may not all be in a single physical enclosure.

System SV-1, SV-2, SV-4

PNT with Assurance

Provide operational and institutional Army Forces PNT information with assurance under the complete range of threat conditions in an affordable, upgradeable, and adaptable manner.

Vision CV-1

Precision (P/Y) Code

The P-Code is a 10.23 MHz PRN code sequence that is 267 days in length. Each of the GPS Satellites is assigned a unique seven-day segment of this code that restarts every Saturday/Sunday midnight GPS time (GPS time is a continuous time scale maintained within one microsecond of UTC, plus or minus a whole number of leap seconds). The P-Code is normally encrypted into the Y-code to protect the user from spoofing. Because the satellites have the capability to transmit either the P- or Y-Code, it is often referred to as the P(Y)-Code. The P(Y)-Code is transmitted by each satellite on both L1 and L2. On L1, the P(Y)-Code is 90 degrees out of carrier phase with the C/A-Code (NAVSTAR, 1996).

Definition N/A

UNCLASSIFIED

43

UNCLASSIFIED

Name Description Type Use

Process Coarse/Acquisition (C/A) Code

A system function that translates C/A-Code into understandable PNT Information.

System Function

SV-4

Process GPS Information

A system function that translates GPS Satellite Information and Pseudo-GPS Satellite Information into understandable PNT Information (Joint, 2011).

System Function

SV-4

Process Military (M)-Code

A system function that translates M-Code into understandable PNT Information.

System Function

SV-4

Process PNT Information

A system function that prepares PNT Information with Assurance for use by PNT Client Systems.

System Function

SV-4

Process Precision (P/Y) Code

A system function that translates P(Y)-Code into understandable PNT Information.

System Function

SV-4

Process Pseudo-GPS Satellite Information

A system function that translates the Pseudo-GPS Satellite Information into usable PNT Information (Joint, 2011).

System Function

SV-4

Protect Against Jamming

A system function that cancels or reduces jamming signals (Joint, 2011).

System Function

SV-4

Provide an Affordable Migration Path to M-Code

This goal is focused on ensuring that the Army can afford to update GPS Receivers to accept M-Code or replace them with GPS Receivers that can accept M-Code. Because the benefits of M-Code are best achieved when every platform and system for a warfighting element (e.g., a brigade combat team) uses M-Code, this goal requires that the number of GPS Receivers and receiver form factors be reduced to a minimum. (Coggins, 2015)

Enterprise Goal

CV-1

Pseudo-GPS Satellite

Terrestrial or aerial-based system or asset that securely transmits the data necessary for a GPS Receiver to calculate a three-dimensional position and time.

System SV-1, SV-2, SV-4

Pseudo-GPS Satellite Information

Information sent from a Pseudo-GPS Satellite that provides a GPS Receiver with the ability to determine current position, velocity, and time.

Exchange Element

SV-1, SV-2, SV-4

Receive GPS Signals using Military GPS Receivers

This goal is focused on the need to use keyed military GPS Receivers that have additional technologies to increase access to GPS signals and filter out false signals, e.g., the SAASM and M-Code receivers after the M-Code migration.

Enterprise Goal

CV-1

Receive PNT Information

A system function that has been designed to receive PNT Information.

System Function

SV-4

Respond to New Threats and Incorporate New Technology

This goal is focused on the need to employ new capabilities or improvements to existing capabilities in response to technology advances or new threats.

Enterprise Goal

CV-1

Standard Antenna A non-anti-jam GPS Antenna. System SV-1

Stay Ahead of the PNT Threat

This goal is focused on enabling an affordable, open systems architecture that is flexible enough to accommodate additional capabilities without incurring expensive system or platform integration and certification costs–a framework that enables a pathway for future innovation– all while providing PNT under current threat conditions. (Coggins, 2015)

Enterprise Goal

CV-1

UNCLASSIFIED

44

UNCLASSIFIED

Name Description Type Use

SV-1 Systems Interface Description Interface Rule 1

Each PNT Module must be connected to at least one PNT Client System.

Interface Rule

SV-1, SV-2, SV-10a

SV-1 Systems Interface Description Interface Rule 2

Each PNT Module may be connected to multiple different PNT Client Systems.

Interface Rule

SV-1, SV-2, SV-10a

SV-1 Systems Interface Description Interface Rule 3

Each PNT Client System must be connected to at least one PNT Module.

Interface Rule

SV-1, SV-2, SV-10a

SV-1 Systems Interface Description Interface Rule 4

Each PNT Client System may be connected to multiple different PNT Modules if it requires PNT Information with Assurance for multiple points, multiple sources of PNT Information with Assurance for a single point, or a mixture of the two.

Interface Rule

SV-1, SV-2, SV-10a

SV-2 Systems Resource Flow Description Interface Rule 1

A given PNT Module and PNT Client System must be connected either by an instance of IF PM-Client_Direct or an instance of IF PM-Client_Ntwk.

Interface Rule

SV-2, SV-10a

SV-2 Systems Resource Flow Description Interface Rule 2

A PNT Module may connect to multiple different PNT Client Systems by instances of IF PM-Client_Direct or an instance of IF PM-Client_Ntwk.

Interface Rule

SV-2, SV-10a

SV-2 Systems Resource Flow Description Interface Rule 3

A PNT Client System may connect to multiple different PNT Modules by instances of IF PM-Client_Direct or an instance of IF PM-Client_Ntwk.

Interface Rule

SV-2, SV-10a

SV-2 Systems Resource Flow Description Port Rule 1

A PNT Module may only include an antenna port if it includes a GPS Receiver Assembly.

Port Rule SV-2, SV-10a

SV-2 Systems Resource Flow Description Port Rule 2

A PNT Module must include at least one of the following types of port: USB port, TIA-232-F port, TIA/EIA-422-B port, ISW antenna, embedded, and Ethernet connector. The PNT Module may include multiple instances of each type of port except ISW Antenna.

Port Rule SV-2, SV-10a

SV-2 Systems Resource Flow Description Port Rule 3

A PNT Client System must include at least one of the following types of port: USB port, TIA-232-F Port, TIA/EIA-422-B port, ISW antenna, embedded, and Ethernet connector. The PNT Client System may include multiple instances of each type of port except ISW Antenna.

Port Rule SV-2, SV-10a

TIA/EIA-422-B Electrical Characteristics of Balanced Voltage Digital Interface Circuits, May 1994

Standard StdV-1, SV-2

TIA/EIA-422-B Port

Serial connector compatible with TIA/EIA-422-B. Port SV-2

TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange.

Standard StdV-1, SV-2

TIA-232-F Port Serial connector compatible with TIA-232-F. Port SV-2

UNCLASSIFIED

45

UNCLASSIFIED

Name Description Type Use

USB USB Revision 3.1 Specification; USB 2 or better is generally acceptable.

Standard StdV-1, SV-2

USB Port USB connector as described by USB Implementers Forum.

Port SV-2

VICTORY Standard

Vehicular Integration for C4ISR/EW Interoperability (VICTORY) Standard Specification 1.6.2, 31 March 2015 or latest at: https://portal.victory-standards.org/SitePages/Home.aspx

Standard StdV-2, SV-2

UNCLASSIFIED

46

UNCLASSIFIED

References

Chairman of the Joint Chiefs of Staff. (2013). Chairman of the Joint Chiefs of Staff Instruction.

2013 CJCS Master Positioning, Navigation, and Timing Plan (MPNTP), CJCSI

6130.01E. J-6.

Chief Information Officer, U.S. Department of Defense. (2010). DoD Reference Architecture

Description. Washington: Office of the Assistant Secretary of Defense, Networks and

Information Integration (OASD/NII).

Chief Information Officer, U.S. Department of Defense. (2012). DoD Architecture Framework Version 2.02. Retrieved January 2014 from http://dodcio.defense.gov/dodaf20.aspx

Coggins, K. (2015). Assured PNT. Army AL&T Magazine. Issue January–March 2015, 86-89.

Department of Defense. (2015). Department of Defense Instruction 4650.08 Positioning, Navigation, and Timing and Navigation Warfare (Navwar). DoD CIO.

Department of Defense Open Systems Architecture Data Rights Team. (2013). DoD Open

Systems Architecture Contract Guidebook for Program Managers v1.1.

IEEE Std. 1471-2000. (2000) IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE, New York.

Joint Requirements Oversight Council (JROC). (2003). JROC Memorandum (JROCM) 022-03, An Evolving Joint Perspective: US Joint Warfare and Crisis Resolution in the 21st Century (JW&CR).

Joint Staff. (2011). Joint Common System Function List. Version 4.0, p. 25. Washington, DC.

Joint Staff J-7. (2017). Joint Operations. Joint Education and Doctrine. JP 3-0, p.IV-3 Suffolk, VA.

NAVSTAR GPS User Equipment Introduction (Public Release Version). (1996). p. 1-7.

Office of the Army Chief Information Officer and CECOM Life Cycle Management Command.

(2013). Army Information Architecture (AIA) v.4.1. Arlington, VA.

Office of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems and Software Engineering (2008). Systems Engineering Guide for Systems of Systems, Version 1.0. Washington, DC: ODUSD(A&T)SSE.

Reference Model for Service Oriented Architecture 1.0, Section 3.1. (2006) The Organization for the Advancement of Structured Information Standards (OASIS). https://docs.oasis-open.org/soa-rm/v1.0/soa-rm.htm

Shyu, H. (2013). Army Positioning, Navigation and Timing (PNT) System of Systems Architecture (SoSA) Strategy. Washington: Office of the Assistant Secretary of the Army, Acquisition, Logistics and Technology.

Systems Engineering. Volume 13, Issue 1, p. 14-27.

U.S. Strategic Command. (2006). Joint Capabilities Document for Positioning, Navigation and Timing.

UNCLASSIFIED

47

UNCLASSIFIED

US Army Signal Center, Concepts, Requirements, and Doctrine Division (CRDD), MRB and US Army Signal Center, TRADOC Capabilities Manager - Tactical Radio (TCM TR). (2010). Initial Capabilities Document for Positioning, Navigation, and Timing (PNT) Assurance, v1.4.