DRAFT
2.1 DoD Level Technical Architectures
2.1.1 Technical Architecture Framework for Information Management
2.1.2 Defense Information Infrastructure Common Operating Environment
2.2 Discipline Specific Technical Architectures
2.2.1 Joint Airborne SIGINT Architecture
2.3 Collection Management and Mission Planning System Architectures
This section provides an overview of the principal sources from which standards were selected and tailored for the ARITA. The ARITA synthesizes across those architectures, identified in the following figure, and tailors them to reflect the needs of airborne reconnaissance systems. In general, the ARITA adopts standards already mandated by the DoD, Services, and intelligence community organizations (e.g., CIO, NSA) to serve the needs of the airborne reconnaissance acquisition community. In addition, future versions of the ARITA will identify follow-on standards initiatives to address standardization areas that are critical for airborne reconnaissance but are not being addressed in other forums.
Figure 2-1: Associated Architectures
2.1.1 Technical Architecture Framework for Information Management
The Technical Architecture Framework for Information Management (TAFIM) provides a technical architecture definition that documents the services, standards, design concepts, components, and configurations used to guide the development of other technical architectures. The underlying premise of the TAFIM is implementation of an open systems environment for information systems. This environment allows information systems to be developed, operated, and maintained independent of applications or proprietary vendor products. Open systems are characterized by their use of standards to define services, interfaces, and formats. The TAFIM uses international, national and federal standards, which are adopted by industry, and standards agreed to by the U.S. and its allies, as well as selected DoD standards. By implementing well-defined, widely-known and consensus-based standards, the DARO can leverage the industry investments in the commercial market and assure a migration path into the future.
2.1.2 Defense Information Infrastructure Common Operating Environment
The Defense Information Infrastructure (DII) Common Operating Environment (COE) describes the requirements for building and integrating C4I systems for the warfighters. It represents the basis for end-user warfighter systems that reconnaissance assets support. This makes the DII COE a very important technical source for developing the ARITA.
The DII COE is a "plug and play" open software architecture designed around a client/server model. It provides implementation details that describe, from a software development perspective, the following:
The DII COE concept is best described as an architecture that is fully compliant with the TAFIM, an approach for building interoperable systems, a collection of reusable software components, a software infrastructure for supporting mission area applications, and a set of guidelines and standards. The guidelines and standards specify how to reuse existing software, and how to properly build new software so that integration is seamless and automated.
Two systems presently use the DII COE: the Global Command and Control System (GCCS), and the Global Combat Support System (GCSS). Both use the same infrastructure and integration approach, and the same COE components for functions that are common between the two systems. GCCS is a C4I system with two main objectives: the near-term replacement of the World-Wide Military Command and Control System (WWMCCS) and the implementation of the C4I For the Warrior concept. GCCS is already fielded at a number of operational CINCs. GCSS is presently under development and is targeted for the warfighting support functions (logistics, transportation, etc.) to provide a system that is fully interoperable with the warfighter C4I system.
2.1.3 Army Technical Architecture
The Army Technical Architecture (ATA) was developed by the Army Staff, Army Systems Engineering Office, Army Science Board, MACOMs, and PEOs/PMs to support the Army Enterprise Strategy. The ATA is based on the TAFIM, DoD Directive 8320 series governing data standardization, and the Army's initiatives for streamlining the acquisition process. It mandates the use of the DII COE for software development, the use of specific network protocols and message formats for data transport, the use of the Defense Data Dictionary System for data management, and the use of IDEF for information modeling. It also establishes human-computer interface standards and delineates standards for information security. The ATA capitalizes on the substantial investment commercial industry has made in information technologies.
2.1.4 DoD Joint Technical Architecture
DISA is leading the creation of the Joint Technical Architecture (JTA) with strong participation from the Services, Agencies, and (recently) the DARO. The JTA mandates certain "rules" to be used across DoD to provide specific services and interfaces in systems being procured today. All standards mandated are required for interoperability (unless there is a strong business case against it); must be mature, technically implementable, and publicly available; and must be consistent with authoritative sources. Commercial product availability is a very high priority. The scope is focused on C4I interoperability for the warfighter, and later versions will address other domains (including the sustaining base, airborne reconnaissance, and weapon systems).
There are currently three on-going efforts for developing discipline-specific technical architectures: (1) Joint Airborne SIGINT Architecture, (2) Common Imagery Ground/Surface System Architecture, and (3) United States Imagery System Standards and Guidelines. These are discussed in the following subsections.
2.2.1 Joint Airborne SIGINT Architecture
The Joint Airborne SIGINT Architecture (JASA) is the DoD's plan for meeting the warfighter's 2010 airborne SIGINT requirements and beyond. The fundamental philosophy behind JASA is to leverage the digital signal processor (DSP) technology investment of commercial industry to counter the ever growing population of varied radio frequency (RF) signals, reflecting a variety of modulation schemes and signal multiplexing structures. By digitizing the signal early in the sensor system, common hardware processing can be used that is independent of signal type, reducing the need for signal specific specialized hardware. This approach to signal processing increases the flexibility and overall capacity of the SIGINT system, which must rapidly respond to the explosion of digital signals in the environment. Key characteristics of JASA are that it will:
The initial version of the JASA functional architecture was approved by the DARSC and published in June 1995. The airborne reconnaissance functional reference model described in Section 3 of this document is the JASA model with adaptations needed for the overall multi-discipline ARITA.
Version 1.0 of the JASA Standards Handbook developed by the JASA Standards Working Group was published in July 1996. Standards identified in that document have been incorporated in the ARITA.
2.2.2 Common Imagery Ground/Surface System Architecture
The first version of the Common Imagery Ground/Surface System (CIGSS) Acquisition Standards Handbook was published in June 1995. Standards from that document have been incorporated in ARITA. The CIGSS architecture is depicted in Figure 2-2.
The CIGSS concept has been approved by the JROC and is fully supported by the Services. It is not a system in the traditional sense; instead, CIGSS is an umbrella program which defines interoperability, performance, and commonality requirements and standards for DoD ground/surface based imagery processing and exploitation systems. It consolidates the following systems into a single DARP project:
Some of the on-going CIGSS projects include revising the CIGSS Acquisition Standards Handbook, development of a Common Imagery Processor, and interfacing CIGSS compliant systems with the following imagery community systems:
Future efforts will include interfacing with the Medium Altitude Endurance (MAE) and High Altitude Endurance (HAE) UAVs and developing common mission planning and mission control functions.
Figure 2-2: Common Imagery Ground/Surface System
2.2.3 United States Imagery System Standards and Guidelines
The United States Imagery System (USIS) Standards and Guidelines focus on information technology standards specifically pertaining to imagery related application programs (i.e., software) integrated in open systems computing environments. The standards identified in the USIS Standards and Guidelines document are closely tied to the imagery-specific services identified in the USIS Objective Architecture Definition and Evolution document and the USIS Technical Architecture Requirements. The USIS imagery standards are controlled by the Imagery Standards Management Committee (ISMC).
The scope of the USIS Standards and Guidelines document is limited to imagery-specific standards that ensure interoperability among elements of the USIS. Other standards that would apply are identified in higher level standards documents, such as the TAFIM, or peer level profiles.
Standards cited in Version 1 of the USIS Standards and Guidelines document, dated 13 October 1995, are incorporated in this ARITA. Other sources include the CIGSS (see Section 2.2.2) and information obtained from various Central Imagery Office CIO-sponsored imagery standards working groups (e.g., video, common interoperable imagery facilities, etc.).
The ARITA would be unacceptably incomplete if it did not tie-in with an effective architecture for collection management and mission planning. However, such an architecture has not been defined by the DoD or Services. Therefore, functions and standards were derived for the ARITA from an assessment of four key systems and their planned migrations:
More detail on these systems is provided in Section 3.8, Planning and Control Functions.
2.3.1 Collection Management Systems
Routine tasking to an operational collection asset (either airborne or national) normally flows via an up-echelon Collection Management Authority (CMA). The process can include provisions to allow ad hoc tasking to be generated directly by a supported task force or task force component. The collection management systems provide functions that support the CMA in prioritizing collection requests (which could be received from numerous users), generating specific tasking for the designated collection asset(s), and tracking the status of that collection tasking and subsequent ISR reporting.
There are two specific collection management systems that will interact with airborne reconnaissance systems in the future (either directly or indirectly).
The Joint Collection Management Tool (JCMT) is the migration system designated by the DoD to be used for all DoD all-source collection management functions (i.e., legacy systems will be phased out as JCMT supersedes them). As such, it will combine IMINT, SIGINT, MASINT, and HUMINT tasking. However, MASINT requirements for collection management tasking are not defined at this time.
The Requirements Management System (RMS) is the migration system designated by the DoD to be used for all DoD imagery collection management functions. An RMS aircraft tasking study has been recently completed which defines a conceptual CONOPS and technical requirements for interfacing with imagery ground stations, AFMSS, and TAMPS. However, this has not been completely reflected in the ARITA since the results have not yet been fully coordinated/approved nor has an implementation plan been developed.
2.3.2 Mission Planning Systems
A multitude of mission planning systems exist today. Many of these are special applications that were designed for specific aircraft and operate on specific hardware suites. There are formal, programmatic efforts underway to consolidate these into several generic systems, two of which were picked as representative systems for purposes of developing the ARITA: The Navy's TAMPS and the Air Force's AFMSS. Note that other specific mission planning systems have been consolidated into these two programs. TAMPS consists of a core and a number of mission planning modules for specific Navy, Marine Corps, and Coast Guard aircraft and weapons. AFMSS contains a core and a number of avionics/ weapons/ electronics (AWE) modules for specific Air Force, Army, and US Special Operations Command aircraft and weapons. Long-term plans call for combining these into one DoD-wide mission planning system.
Both TAMPS and AFMSS have adopted the same general architectural design and acquisition approach: (1) common, centrally procured hardware; (2) common, centrally procured and managed software; and (3) aircraft-specific software modules and data transfer devices that are (generally) procured and managed by aircraft program managers. For example, both the AFMSS system and the TAMPS system consist of common, core software sets and specific AWE (avionics/weapons/electronics) modules for supported aircraft.
Basic, core functions provided by both mission planning systems include:
While both the TAMPS and AFMSS programs show plans to provide mission planning capabilities for reconnaissance platforms (such as the U-2, UAVs, RC-135, EP-3, F/A-18 and others), the plans are generally for platform and navigation planning only (e.g., flight path, threat avoidance, take-off and landing calculations, fuel consumption, etc.). Mission planning modules for the reconnaissance sensor system payloads and communications system planning are currently not in the baseline.
DRAFT