Back to: [ DARO Products ]

Defense Airborne Reconnaissance Office

Common Imagery Ground/Surface System (CIGSS)

Acquisition Standards Handbook

(CIGSS-Hdbk)

Version 1.0

19 July 1995

19 July 1995

19 July 1995

Common Imagery Ground/Surface System (CIGSS)

Acquisition Standards Handbook

The Defense Airborne Reconnaissance Office (DARO) and the Central Imagery Office (CIO) are pleased to present the first version of the Common Imagery Ground/Surface System (CIGSS) Acquisition Standards Handbook. The CIGSS Handbook has been prepared under joint DARO and CIO direction by a working group with broad imagery community participation. This version of the CIGSS Handbook is intended to facilitate the migration of existing systems to a common interoperable baseline. Subsequent versions will address the longer-range objective of developing true plug and play component-level compatibility.

The CIGSS program encompasses a family of scalable, extensible, and interoperable image processing and exploitation systems. These systems will provide the warfighter with rapid remote access to airborne and national imagery and imagery products; consequently, CIGSS is a key element within the United States Imagery System 2000 (USIS) and Intelligence Community strategy.

The CIGSS Acquisition Handbook differs from the traditional system specification. In lieu of functional and performance requirements, the handbook specifies an open system approach based upon commercial standards and military adaptations of commercial standards. These standards provide functional and performance envelopes to guide design and component selection. This approach has the potential to increase design competition, stimulate innovative uses of commercial off-the-shelf software and components, reduce software maintenance and upgrade costs, and protect capital investments.

As we take the handbook through its next phase, we look forward to your ideas, critical comments, and renewed support.

CIGSS Aquisition Handbook

Defense Airborne Reconnaissance Office

Common Imagery Ground/Surface System (CIGSS)

Acquisition Standards Handbook

(CIGSS-Hdbk)

Version 1.0

19 July 1995

Table of Contents

FOREWORD

1. GENERAL
1.1 Scope
1.2 Architectural Overview
1.3 Open Systems and Distributed Computing
1.3.1 Scalability
1.3.2 Extensibility
1.4 Migration of Existing Systems and Interoperability
2. DOCUMENTS
2.1 Commercial Standards
2.2 DARO, CIO, DIA, and DISA Documents
2.3 Military Standards
2.4 InterRange Instrumentation Group
2.5 Military Handbooks
2.6 Joint Circulars
2.7 Internet Requests for Comment and Internet Architecture Board Standards
2.8 NIST Implementation Agreements
2.9 Applicability of Standards
3. ARCHITECTURAL FEATURES
3.1 USIS Architectural Elements
3.2 Collection Element
3.2.1 Collection Element Service
3.2.2 Collection Element Interfaces
3.3 Processing Element
3.3.1 Processing Element Services
3.3.2 Processing Element Interfaces
3.4 Dissemination Elements
3.4.1 Data Flow Services
3.4.1.1 Network Services
3.4.1.2 TCP
3.4.1.3 IP
3.4.1.4 TACO-2
3.4.2 Format Services
3.4.3 Management Services
3.5 Archive Elements
3.5.1 Archive Element Services
3.5.2 Archive Element Interfaces
3.5.3 Image Product Archive
3.6 Management Element
3.6.1 Nominations Management Services
3.6.2 COTS and GOTS Support Software
3.6.3 Operating System
3.6.4 Mission Planning and Control Functions
3.7 Site Infrastructure Elements
3.7.1 Physical Layer Connections
3.7.2 Opto-Mechanical
3.7.3 Electrical
3.7.4 Mass Storage
3.7.5 Workstations
3.7.6 Reference Databases
3.7.7 Local Area Networks and High Speed Switching
3.7.7.1 Ethernet
3.7.7.2 High Performance Parallel Interface
3.7.7.3 Fiber-Distributed Data Interface
3.7.7.4 Synchronous Optical Network/Synchronous Digital Hierarchy
3.7.7.5 Fibre Channel
3.7.7.6 Technology Migration
3.7.7.7 Throughput and Sizing Considerations
3.7.7.8 Selecting Feasible LAN Technologies
3.8 Digital Exploitation Element
3.8.1 Image Manipulation and Analysis Services
3.8.2 Exploitation Applications
4. IMPLEMENTATION CONSIDERATIONS (TBD)
4.1 Software Development
4.1.1 Language and Object Oriented Methodology
4.1.2 Test and Evaluation
4.2 NITFS Certification
4.3 Security Isolation
ANNEX A
A.1 IESS
A.2 Image Product Archive
A.3 RULER Mensuration Application
Annex B
Annex C
C.1 Advanced Synthetic Aperture Radar System (ASARS-2) SDE
C.2 Tactical Exploitation Group (TEG) and Advanced Tactical Air Reconnaissance System (ATARS) SDE
Annex D Acronyms and Definitions

FOREWORD

This is the initial baseline reference for the Common Imagery Ground/Surface System Acquisition Standards Handbook (CIGSS Hdbk). The CIGSS Hdbk has been developed as a Joint Defense Airborne Reconnaissance Office (DARO) and Central Imagery Office (CIO) initiative and prepared by the CIGSS Acquisition Standards Handbook Working Group. The membership of the CIGSS Hdbk working group included government and contractor representatives from the National Imagery Community (NIC), Joint and Service Program Offices, and Service Staffs involved in the development and acquisition of imagery ground and surface systems.

The CIGSS Hdbk will evolve in three phases. The primary focus of the Working Group during the first phase (Jan - July 1995) is to specify a common image file format, establish common physical and data link standards, establish common media inputs and outputs, and draft the rudiments of the remaining baseline architecture. A common image file format is critical for the external exchange of data and is a key factor in identifying migration paths towards true interoperability. In addition, the mandated interfaces and data formats, including tape, will be defined. Establishing common physical exchange media, and physical and data link standards will address the issues related to physical and electrical connectivity, framing, synchronization, error and flow control needed for the reliable transfer of image data. The Common Image Processor (CIP), a major component of CIGSS, is being worked in a separate but closely allied study. It is envisioned that existing systems will migrate towards the functionality of the CIGSS through a sequence of modifications. The CIGSS Hdbk Version 1.0 will be published in July 1995. Agreement to this level enables contract modifications for implementation of these migration paths to be let.

During the second phase (July 1995 - April 1996) the remaining issues will be worked so that systems migration to CIGSS can be completed. The work during this phase concerns the issues associated with employing network technology, achieving interoperability with transitional exploitation systems, and establishing and specifying the minimum functionality and capabilities to be fielded. The first complete CIGSS Acquisition Support Handbook Version 2.0 will be published by April 1996.

The third phase provides for successive versions of the CIGSS Hdbk to be prepared as needed to meet changing requirements and keep pace with advances in image processing and computer technology. During the second phase, and continuing into the third phase as needed, the interface control documents (ICD) and Application Program Interfaces (API) that describe the key points of interoperability will be developed. It is anticipated that these ICDs and APIs will cover the following areas:

As the objective system evolves, specifications would be needed for components where commonality, rather than interoperability alone, is required. For example, future advances in computer technology may enable a common application platform specification to be developed that is commercially supported by multiple manufacturers.

1. GENERAL

a. The purpose for this handbook is to specify a set of standards, consistent with the Department of Defense Intelligence Information System (DoDIIS) reference model, the United States Imagery System (USIS) profile, and the Open System Interconnection (OSI) model to support the migration of current imagery ground stations towards a common interoperable baseline and to manage the interoperability of subsequent Service and Agency acquisitions of the Common Imagery Ground Surface System (CIGSS). The handbook also draws information from the Joint Operational Requirements Document, the CIGSS Concept of Operations, and the Airborne Reconnaissance Technical Architecture Program Plan (ARTAPP).

b. The DoDIIS, USIS, and ARTAPP are application environment profiles (AEP) derived from formal base standards and standardized profiles. Base standards are conventions for doing things that cross communities of users while standardized profiles are a consistent set of standards that have been selected for use by a specific community. In addition, the DoD Technical Architecture Framework for Information Management (TAFIM), Adopted Information Technology Standards (AITS) is an evolving AEP for the DoD information management infrastructure that is embodied in the ARTAPP. The TAFIM/AITS does not at the present time support certain of the high data rate network technologies that may be used in CIGSS. For other functions, the TAFIM/AITS generally overlaps the DoDIIS. The TAFIM/AITS is referenced because developers should take their guidance for POSIX implementation from the TAFIM.

c. This handbook selects standards from the referenced AEPs that apply to CIGSS acquisitions and excludes others from use. For example, the DoDIIS incorporates the Portable Operating System for Computing Environments Open System Environment, and the Portable Operating System Interface (POSIX) Standardized Profile for providing operating system services; and, also permits the Tagged Image File Format base standard to be used as one of the object interchange services. In this handbook we require some elements of POSIX and permit the optional use of others, and we exclude the use of TIFF for public data, selecting instead, the National Imagery Transmission Format with Support Data Extensions itself a DoDIIS community accepted standard, as the common exchange format.

d. Some standards are not discussed but are only cited in section 2 or are implied by reference to other standards. For example, the standard, "ANSI X3.135 (FIPS PUB 127-2), Database Language - SQL" is part of both DoDIIS and the USIS Standards Profile for Imagery Archives (SPIA) and has been implemented in the Image Product Archive (IPA). It should be noted, that the IPA is an instance of an archive element. As long as developers comply with the standards specified in this handbook, they can implement the Archive Element in the CIGSS in any way they want, and do not have to copy the IPA implementation. With respect to SQL, following the SPIA establishes SQL as a requirement for querying public data. Although the SQL standard appears in section 2, it does not need to be a subject of direct discussion within the text.

e. The approach taken in the CIGSS handbook to managing airborne and space-based imaging systems interoperability, retains the flexibility needed for Services and Agencies to exercise acquisition prerogatives and effect the transfer of new technology when required. The handbook does not preclude custom closed solutions to image processing problems, but does favor the integration and utilization of COTS hardware and software toward that end. The integration of COTS items is facilitated by specifying an open systems approach, the key elements of which are: transportable COTS and GOTS software; a high degree of platform independence; common protocols and transmission file formats; standardized interfaces; standard exchange media and recording standards; and, a common set of component and service definitions to guide the acquisition process.

f. The handbook is organized into four sections and annexes. Section 1 introduces the conceptual CIGSS architecture and explains how it supports scalability, extensibility, and mission tailoring. This section also describes the migration of existing systems towards a common interoperable baseline. Two levels of interoperability are defined which correspond approximately to DoDIIS levels 4 and 5. Elements of DoDIIS level 6 (e.g., the global information repository enabling function) will be implemented at both handbook levels as the Image Product Archive and remote browsing and accessing capabilities are developed. Section 2 consists of a list of standards documents, by type, that are referenced within the handbook.

g. Section 3 describes the major architectural features and components of the CIGSS and maps these to the United States Imagery System (USIS) 2000 architectural elements. The USIS 2000 program was developed under the cognizance of the Central Imagery Office to promote data, service, and resource sharing among the military and national agency entities that comprise the United States imagery intelligence enterprise. The USIS 2000 architectural elements: Collection, Processing, Exploitation, Dissemination, Archive, Management, Site Infrastructure, and Global Communications provide a system independent view of the processes by which the military and national leadership manage imagery intelligence. The USIS 2000 architecture specifically establishes the critical points of interoperability within the enterprise where interface standardization is required to achieve interoperability.

h. The DoDIIS reference model and open systems architecture standards were developed for the Defense Intelligence Agency (DIA) by the Air Force Systems Command with the technical assistance of the MITRE Corporation. The DoDIIS standards are managed by the DoDIIS Management Board at DIA. The DoDIIS Standards Document prescribes the interface requirements for the seven service areas defined in the DoDIIS Reference Model: Operating System Services, User Interface Services, Software Development Environment, Object Management Services, Object Interchange Services, Object Manipulation Services, and Networking Services. The applications and services described under DoDIIS are distributed among the USIS architectural elements. The DoDIIS reference model is the basis for the Airborne Reconnaissance Technical Architecture Program Plan.

i. A third reference for the CIGSS architecture is the OSI model which provides the definitions of protocols and services for distributed processing among computers, workstations and terminals. The OSI model is important to this discussion because it provides the framework for the definition of network services and technologies used in CIGSS. The DoDIIS standards incorporate parts of the OSI model.

j. Section 4 is reserved for implementation and planning details. Although CIGSS will make extensive use of commercial and government furnished products, some software development will be needed to add tools and filters, modify algorithms, and test and integrate packages. Additionally, some technical decisions may be needed in choosing among available hardware or software. This section will discuss such issues.

k. Annexes are reserved to provide information about the implementation of standards, descriptions of COTS and GOTS applications, and migration approaches that would generally be useful for acquisition authorities in preparing requests for proposals. These annexes will also include references to the Support Data Extensions needed to encode imagery data into the NITFS.

1.1 Scope

a. The Common Imagery Ground/Surface System (CIGSS) is a family of image processing and exploitation systems that can accept unprocessed or processed (e.g., from sensor platforms with on-board processing) data from electronic or tape media sources, and derive imagery and imagery products from that data for military intelligence and operations. Some CIGSS missions may also require archiving and disseminating unexploited imagery. The CIGSS operates on data received from any of the electro-optical, infrared, synthetic aperture radar, and multi-spectral spaced-based and airborne sensors used by the military forces and national agencies.

b. Imagery is collected by electro-optical (EO), infrared (IR), synthetic aperture radar (SAR), and multi-spectral imagery (MSI) sensors from national, tactical, and commercial sources. The imagery, in the form of multiplexed data streams or analog video is unique to each sensor technology. Data may be downlinked directly to a collocated receive element, captured on tape recorders at a link receiver, relayed through a satellite or aircraft to fixed or forward deployed ground stations, or received on magnetic tape from reconnaissance aircraft upon completion of a mission. The CIGSS processes the received data into analyst-exploitable visual images; provides the facilities and tools for data fusion and exploitation; archives the imagery and imagery products generated for military and intelligence operations; and, distributes annotated images and image-derived intelligence products to local and remote military users via electronic and tape media means.

c. The CIP reads and processes the incoming data. Still image processing at the CIP includes making the radiometric and geometric corrections needed to prepare an exploitable image. Video is normally fed through the CIP for real-time display to enable interactive platform or sensor control, and may be stored for subsequent editing and film clip generation or frame extraction. Synthetic Aperture Radar (SAR) imagery requires intensive processing within the CIP to provide an exploitable image. Among the algorithms which may be used to form an image from radar returns are: single patch and subframe processing in polar format; overlapped subaperture; planar subarray; range migration; chirp scaling; range-doppler; and back projection. The selection of these algorithms is made within the CIP.

d. Each CIGSS is tailored to specific missions; consequently, there are variations in the physical configurations, support software, operating and logistics requirements among CIGSS compliant systems. Some CIGSS will be mounted in deployable shelters, others may be installed in combat vehicles such as the High Mobility Multi-Purpose Wheeled Vehicle (HMMWV); some will be rack mounted at fixed sites, others will be installed on board ships. All CIGSS systems will be interoperable via the tactical, strategic, physical and commercial communications allocated to the using Service (during peacetime or in-garrison) and to the JTF Commander during crisis and wartime deployments.

e. The CIGSS will provide deployed commanders with detailed, near-real-time information on enemy forces for targeting and mission planning. Through the remote access capabilities in CIGSS, a deployed Joint Task Force (JTF) commander will be able to query, browse, download, and utilize reconnaissance information from any other CIGSS within the theater. The CIGSS will be globally deployable using a variety of inter-theater lift/mobility assets. To accommodate tactical movements from remote areas, all components shall be deployable within C130 aircraft. All deployable CIGSS components can be interchanged to facilitate field tailoring and support JTF missions. Initially this requirement for interchangeability will apply to the capability to internet workstations and major subsegments. As CIGSS and computer technology evolve, it may be prudent to specify common components, instead of interoperable components, to ensure the maximum flexibility for deployed commanders.

f. This handbook is a management tool for promoting interoperability among CIGSS compliant imagery systems by establishing a standards-based architecture that is required for all Service and Agency imagery ground system acquisitions. It is based upon the notional architecture developed by DARO and can be expected to evolve with technology as better and more productive methods are found to solve problems in the intelligence domain.

1.2 Architectural Overview

a. The top-level CIGSS architecture is a client-server network (Figure 1-1). This terminology provides a useful way of thinking about bandwidth and service allocations in a distributed computing environment. In its original context it served to distinguish large database systems where information processing was shared by workstations and computers (often customized, the servers), from those systems where a number of dumb terminals hung off a network connected to a host computer which did all the work. Client-server models have become more sophisticated as commercial computers have moved away from centralized mainframes and desk-top workstations and networking capability have become increasingly powerful. A client-server architecture now prescribes the division of an application into separate processes capable of operating on different central processing units (CPU) connected over a network. The server can be a minicomputer, workstation, or microprocessor with attached storage devices. Client applications don't assume any specific server location on the network.

b. A client is usually a workstation at which a primary function (e.g., exploitation) is accomplished. The client may be directly connected to the primary local area network or it may reside on a subnetwork of other clients and servers. Clients host applications or parts of applications that perform the functions of collection management, data archiving, processing, exploitation, and dissemination. The use of the workstation paradigm for a client implies a human in the loop. In its general context, a client need not include a human in its operation though the vast majority of clients are workstations with which a human operator interacts. The user should interact with client processes through a high level interface which presents little if any details about the underlying communications and processing details as possible. It is particularly important to isolate the client from the interprocess application so that details about the communications mechanism could change without requiring a revision to the client applications. Clients can be served by multiple servers.

c. The ability to include subnetworks within the overall client-server architecture provides a convenient way to migrate towards a future CIGSS from the current base of legacy systems. It also means that a CIGSS may be configured as a network of networks. The number of interconnected networks would in most cases be small. A high volume CIGSS compliant facility may interconnect a high bandwidth network for primary processing with lower bandwidth networks for exploitation and product archiving.

Figure 1-1. An Architectural Overview of CIGSS

d. The client-server architecture distributes computing power and facilitates hardware and software extensibility and scalability. Computing power may be increased by adding faster, more capable workstations and servers, and by off-loading some of the computing requirements to intelligent peripherals. The CIGSS computing power is the capability represented by networked desktop computers, servers, and intelligent devices that exchange or manipulate information.

e. Although the advantages for using a client-server architecture are compelling, there can be significant integration problems. The success of a client-server architecture depends almost entirely upon network performance. The handbook permits a wide choice of network technologies assuming that the selection of a specific technology will be based upon a detailed system engineering analysis. FDDI and ethernet standards are specified as the lowest common denominator to ensure connectivity for transportable components; however, the handbook strongly recommends that CIGSS migrate towards an ATM network as rapidly as possible. The requirement for FDDI connectivity is waived for systems designed for ATM.

f. Security imposes complexity upon the client-server architecture and generally degrades performance. The complexity is required because there must be a means for ensuring multi-level access only to authorized clients. Several layers of security services are required to prevent unauthorized disclosure. Password protection, message authentication, and encryption are representative of the services that must be provided in the CIGSS environment which are not intrinsically part of the client-server model.

g. Client-server networks require systems management, performance monitoring, fault detection, fault isolation, and maintenance services. The use of a distributed object management model, the off loading of servers onto a separate FDDI ring, and the use of high speed switches to establish point-to-point connections between clients and servers are examples of design options to client-server architectures.

h. The CIGSS includes a Common Imagery Processor (CIP) or its equivalent, to accept data from electronic and tape sources, and produce a visually exploitable image; an Image Product Archive (IPA) for storing imagery and intelligence products for local and external dissemination; and, in some instances, a NIS to manage the request and dissemination of NIC collected primary imagery to the CIGSS LAN in near-real time. The NIS also provides a gateway for CIGSS processed imagery to be disseminated in-theater, intra-theater, and across the global NIC infrastructure.

i. The CIGSS architecture has the flexibility to integrate new technology, either through the evolution of its core components, or through the replacement of these components with new devices. Other CIGSS components include workstations for collection, requirements, dissemination, and exploitation management; and an external dissemination capability.

j. The CIP is currently under study and a prototype has yet to be developed. In the interim, migration towards the functionality and services provided by the CIP will require enhancing the capability of legacy system processors to handle data from different types of sensors. The primary objective in this aspect of migration towards interoperability is this integration of airborne data with national imagery at those facilities that have this dual requirement.

k. The IPA is a scalable system for the storage, query, response, and transfer of imagery products. It has been demonstrated as part of the CIO A3I program and is presently in production. The IPA stores imagery products by means of high capacity disk arrays or magnetic tape-based devices.

l. The Exploitation Workstations provide the COTS/GOTS softcopy exploitation capability (e.g., RULER for image mensuration), as well as providing the user with access to the Imagery Exploitation Support System (IESS) and the Requirements Management System (RMS) for the ordering, management, and dissemination of products over various media and external communications networks.

m. The IESS will provide the exploitation requirements management, imagery dissemination management, softcopy/hardcopy exploitation task management, and the database management for the CIGSS. In addition, the IESS provides brokered cataloging of NIS imagery available to the Image Product Archive (IPA) Server.

n. The NIS is a system developed for the dissemination of NIC imagery and complies with the USIS 2000 vision. It is a commercial standards, 100 percent COTS-hardware based system that is scalable in performance and functionality and configurable to meet user specific requirements. Imagery is disseminated from the NIS to COTS exploitation workstations, high performance NIC exploitation workstations, tapes, media, IPA and to ultrahigh resolution Hardcopy Reconstruction Unit (HRU) or advanced hardcopy units. Imagery data is provided in both NITF and the Tape Format Requirements Document (TFRD) format to ensure interoperability across a large number of currently deployed imagery exploitation systems. The NIS interfaces with the IESS to request imagery from the NIC infrastructure and track requirements satisfaction through completion of the dissemination request. The NIS is currently in production. Development of the next generation NIS will begin in 1996 with production deliveries starting 3Q CY96.

o. There are many solutions that fit the framework of the specified architecture; consequently, a mission analysis backed by engineering trade and cost to benefit studies are required before specific hardware and software solutions can be developed. The thrust of this handbook is to foster innovative, cost effective solutions that achieve interoperability at specified software and hardware interfaces. Annexes to this handbook will be published that describe the COTS solutions, consistent with this handbook, that users develop for specific mission profiles.

1.3 Open Systems and Distributed Computing

a. There are design limits to the functionality and performance of every system; however, those limits are not necessarily fixed over the useful life of the system. CIGSS takes the approach of broadening its potential functional and performance envelopes by adopting a scalable and extensible distributed computing environment based upon a client-server architecture and OSI protocols and services. A client/server application is usually characterized by distributed logic; part of the application resides on the client (e.g., a workstation or terminal) and the remaining parts and data reside on one or more servers. A client in an OSI or open system is able to access an OSI service anywhere in the system and normally maintains the presentation layer of an application.

b. Client-server applications are historically associated with large databases and database management systems. The partitioning of a client-server application normally takes advantage of the graphic user interface (GUI) on the client and the database engine on the server; however, any computer may be both a client and a server since these concepts really represent the transitory relations involved in the storage, retrieval, and manipulation of data.

c. Clients and servers are physically interconnected by a local area network and logically connected through an OSI-compliant protocol stack. The degree of compliance is specified in this handbook in terms of required services and applications.

d. A system may be contained within a single workstation or be distributed among an ensemble of workstations, terminals, processors, and peripheral devices. We use the word system to describe a functionally complete CIGSS and the word component for single workstations, processing units, and peripherals. The word subsystem describes deployable ensembles of equipment and software that provide only part of the functionality of a complete CIGSS.

e. An open system is concerned with the exchange of information between components that communicate via a network. Two basic factors must be present to exchange information. First, the components and subsystems must be physically and logically connected; that is, the devices must be capable of transmitting, receiving, sensing, and detecting the bits transferred. Second, the data must be organized in a way that each system recognizes. This latter property involves the compatibility of file formats. The selected standards emphasize these factors.

1.3.1 Scalability

a. Scalability applies to hardware and software. Hardware scalability allows the addition or deletion of functionally equivalent platforms or components with different attributes (size, performance, etc.). Software scalability provides equivalent functionality on hardware with different physical and performance characteristics or with substantially different amounts of data. Examples of scalability include the ability to add or delete workstations, add on-line storage, increase information transfer rates, adjust window sizes to accommodate different size monitors, and operate on images of arbitrary sizes.

b. Scalability increases the design options available to program offices for tailoring acquisitions to mission requirements. This allows both the interconnection of equipment vans, and the addition of workstations, processing capabilities, peripherals, and software applications to augment a CIGSS when needed to meet Joint Task Force requirements. For example, imagery exploitation at lower echelons generally requires only a small fraction of the computing power of a major exploitation center. Scaling processor power to meet these distinct requirements is a way to avoid the cost, space and labor impacts of unneeded equipment. In addition to reducing development and acquisition costs, scalability minimizes the force structure and costs associated with operations and maintenance of the fielded system.

1.3.2 Extensibility

a. Extensibility provides the means to vary functionality. Extensibility ensures that new hardware or software capabilities can be readily added. In a true extensible environment, new software capabilities can be added without rewriting and recompiling old code; new hardware functionality and capabilities can be added by connecting boards and external devices to an existing configuration.

b. Examples of software extensibility are the plug-in filters that are standard features within commercial image processing, desktop publishing, and spreadsheet software, and the drop-in system extensions used to modify and enhance system operating environments. Examples of extensible hardware include the modular test equipment manufactured by most leading vendors, and the SUCCESS radio system in use by the military. True extensibility is a goal for the objective CIGSS. Extensibility can be accommodated at various levels. In CIGSS, the primary concern is ensuring extensibility at the component level.

1.4 Migration of Existing Systems and Interoperability

a. There are nine IMINT ground and afloat stations within the Defense Airborne Reconnaissance Program (DARO) that have been developed or fielded independently and prior to the advent of CIGSS. These systems are:

b. The CIGSS program will evolve to its objective system by migrating current systems to a common set of standards and Joint interoperability requirements. There are two distinct levels of interoperability. The first achieves interoperability at the system level and is largely addressed through standardizing inputs to and outputs from CIGSS compliant systems. Interoperability is achieved by requiring each CIGSS to be capable of receiving imagery and related data in standard commercial tape formats or prescribed formats over specified data links and of transmitting imagery and imagery products in compliance with NITFS 2.0. All references to standard or commercial tape formats include: ANSI ID-1, Ampex Digital Cassette Recording System Improved (DCSRi), 8mm, Hi8, VHS, and S-VHS. The latter four types are considered Low Cost Media (LCM). Fewer variant types within both the LCM and the high performance tape categories are expected in the future. The LCM devices defined in S2035 for the NIS are the Metrum RSP 2150 and Exabyte 8500. Each CIGSS shall determine which tape formats to support based upon mission requirements. Coordination with the National Media Lab should be made to obtain the latest test results and information about the state of magnetic media before making acquisition decisions. Distribution of imagery data on magnetic tape using these standard tape formats may also be required. From a DoDIIS information perspective, system level interoperability will achieve the ability to directly exchange complex (e.g., annotated imagery, video) documents between CIGSS.

c. System level interoperability also requires the provision of compatible communications media/mode and suitable bandwidths to enable imagery transfer. Media interface units connect CIGSS to the global communications element. The CIGSS shall be designed to use existing military terrestrial and spaced-based communications means including leased commercial telecommunications services. CIGSS shall also support transfer of data and imagery via standard format tapes.

d. The attainment of system level interoperability is the first objective in migrating existing systems towards a common interoperable baseline. This handbook specifies the file formats, physical and data link protocols, tape formats, and minimum software functionality to ensure that any two systems can exchange imagery, support and management data, decompress, and manipulate images on internal softcopy workstations.

Figure 1-2. CIGSS to CIGSS System Level Interoperability

e. The second level of interoperability concerns the ability to field-tailor ground stations to mission requirements. This level of interoperability is not intended for CIGSS installations afloat, since those systems must be tightly integrated into existing shipboard spaces and would not normally be transported to augment another location. Interoperability of shipboard CIGSS will be limited to electronic and tape based exchange.

f. The interconnection of major components (e.g., segments or subsystems) from different systems enables the field configuring and tailoring of a ground station for contingency operations. This may be accomplished by connecting major components to operate as subnetworks through interface units, routers or gateways (depending upon the base technology) to provide protocol translation, buffering and reassembly of data packets for delivery. A major component from an existing system is defined as a transportable assembly providing the comparable functionality of processing, archiving, exploitation, or dissemination; consequently, it may be as large as a van of equipment (e.g., an ETRAC or MIES) or as small as a separable terminal. As the current suite of systems migrate towards the CIGSS architecture, component level interoperability means that a CIP, or an archive such as the IPA, a national interface such as the NIS, or an exploitation subsystem such as an IESS from one CIGSS can be connected to another CIGSS to increase its processing, archival or exploitation throughput capability. The operational flexibility gained will enable more users to share and manipulate imagery while the path to component interchangeability will extend the database, data element, display, and query standards.

g. The long-term objective of the CIGSS program is to replace stovepiped operations with a suite of interoperable imagery ground stations and components. In the near-term to mid-term this objective will be served by the planned migration of existing systems towards common standards. Services and agencies will be responsible for modifying existing systems to incorporate the standards identified in this handbook and for tailoring those CIGSS acquisitions to meet specific mission requirements. The adherence to these standards will eventually provide an inventory of modular, transportable, and scalable components and subsystems to meet JTF requirements. This will decrease the logistics burden and improve responsiveness to warfighter needs for automation, high speed accessibility to mission critical data, and reduced delays in processing, exploiting, preparing, and disseminating intelligence products.

h. Each CIGSS can be tailored by changing the number of softcopy exploitation, technical and management support workstations, selecting the LAN technology and CIP configuration most appropriate for the type and amount of mission data to be processed, and increasing or decreasing the amount of on-line storage. CIGSS can also be tailored by adding software, servers, data storage devices, workstations, and peripherals to handle mission specific requirements. The standards described in this handbook require that the products of any mission specific intelligence processing be stored in the specified standard formats and be accessible to the warfighter via military communications protocols, links, and tapes.

2. DOCUMENTS

The standards referenced in this handbook are derived from the following sources which include Standardized Profiles (SP) and Application Environment Profiles (AEP) in addition to commercial and military Base Standards. There is inherent overlap because the Standards Profiles and Application Environment Profiles reference the Base Standards. Publication dates are not provided. The latest available standard should always be used. CIGSS program offices and contractors can obtain the most current version from the issuing authority.

2.1 Commercial Standards

IEEE 802.2 (ISO8802/2) Logical Link Control

IEEE 802.3 (ISO8802/3) CSMA/CD-MAC (Ethernet)

IEEE 802.5 (ISO8802/5) Token Ring MAC (FDDI)

IEEE 802.12 Fast Ethernet

IEEE/P1003.0 Draft Guide to the POSIX Open System Environment

IEEE/P1003.1 Systems Services Interface (POSIX.1)

IEEE/P1003.2 Shell and Tools Interface (POSIX.2) with User Portability Extension (UPE)

IEEE/P1003.3 Test Assertions (POSIX.3)

IEEE/P1003.4 Real-Time Extension for POSIX (POSIX.4)

IEEE/P1003.5 Ada Language Binding (POSIX.5)

IEEE/P1003.6 Security Interface for POSIX (POSIX.6)

IEEE/P1003.7 System Administration (POSIX.7)

IEEE/P1003.8 Transparent File Access (POSIX.8)

IEEE/P1003.11 Transaction Processing (POSIX.11)

IEEE/P1003.12 Network Interprocess Communications (POSIX.12)

IEEE/P1003.13 Namespace/Directory Service (POSIX.13)

ANSI X3T9.3 HiPPI (High Performance Parallel Interface)

ANSI X3T9.5 FDDI (Fiber-distributed Data Interface)

IEEE 9314-1 FDDI Physical Layer

IEEE 9314-2 FDDI Medium Access

IEEE 9314-3 FDDI Multimode fiber

ANSI X3.175-1990 19-MM Type ID-1 Recorded Instrumentation - Digital Cassette Tape Format

CCITT Rec G.707,708,709 SONET / SDH OC-3 to OC-48

ATM-Forum: ATM User-Network

Interface Specification Version 3 Asynchronous Transfer Mode (ATM)

EIA NTSC 4.43 National Television Standards Committee (US Composite B/W and Color TV System)

EIA RS-170A Video Timing Specification

PAL Phase Alternate Lock (European TV)

VHS Video Helical Scan recording standard

SVHS VHS recording standard characterized by wider video bandwidth and effective resolution than VHS

8 mm Standard 8mm video format recording standard

Hi-8 Hi-band 8mm video format recording standard characterized by wider video bandwidth and frequency deviation than standard 8 mm

2.2 DARO, CIO, DIA, and DISA Documents

DARO 52110-094/95 Defense Airborne Reconnaissance Office, Airborne Reconnaissance Technical Architecture Program Plan

CIO (No number yet) USIS Standards and Guidelines (USIS Standards, Guidelines, and Conventions)

CIO ASD SIA 0594 0000 United States Imagery System Standards Profile for Imagery Archives (SPIA)

CIO ASD SIA 0794 0000 United States Imagery System Standards Profile for Image Distribution (SPID)

Note: The SPID will be replaced after the A3I contract is finished by the Intelligence Community Standards Profile, an ISB project just beginning.

EARS-1: USIS Directive 1-4-1 Intelligence Reports

CIO TCS-037-028/94 CIO SDE Specification for NITFS Products coming from NIS v1.0 (v1.1 in draft)

DIA DoDIIS Reference Model DoDIIS Reference Model for the 1990's (Oct 1991)

DIA DoDIIS Standards Document DoDIIS Standards Document (December 1991)

DoD TAFIM DoD Technical Architecture Framework for Information Management, Adopted Information Technology Standards (AITS)

DOD 5200.28 Security Requirements for Automated Systems

DOD 5200.28-STD DOD Trusted Computer System Evaluation Criteria (Orange Book)

NCSC-TG-005 Trusted Network Interpretation (Red Book)

NCSC-TG-021 Trusted DBMS Interpretation

2.3 Military Standards

MIL-STD-188-184 Interoperability and Performance Standard for the Digital Control Waveform

MIL-STD-188-220A Interoperability Standard for Digital Message Transfer Device Subsystems

MIL-STD-2045-xxxx Internet Protocol (IP)

MIL-STD-2045-13500 Point-to-Point Protocol (PPP)

MIL-STD-2045-14502-1 Transmission Control Protocol (TCP)

MIL-STD-2045-17504 File Transfer Protocol (FTP)

MIL-STD-2500A National Imagery Transmission Format (NITF) Version 2.0

MIL-STD-2525 Graphical Situation Display

MIL-STD-2045-44500 (NOTICE 1) Tactical Communications Protocol (TACO-2)

MIL-STD-188-198A Joint Photographic Experts Group (JPEG) Image Compression

MIL-STD-188-199 Vector Quantization Decompression for the National Imagery Transmission Format Standard

MIL-STD-2525 Graphical Situation Display

MIL-STD-2301 CGM Implementation Standard for NITFS

NATO STANAG 7023/7024 NATO Standardization Agreement (Tape Formats)

2.4 InterRange Instrumentation Group

IRIG Standard 106-93 Telemetry Standards

2.5 Military Handbooks

MIL-HDBK-1300 National Imagery Transmission Format Standard (NITFS)

2.6 Joint Circulars

JIEO Circ 9214 Joint/Combined Interface Procedure (JCIP) Secondary Imagery Dissemination System (SIDS) to COMSEC Equipment for Point-to-Point TACO Communications

JIEO Circ 9008 NITFS Certification Test & Evaluation Plan

2.7 Internet Requests for Comment and Internet Architecture Board Standards

Internet Architecture Board (IAB) Standards (STD) are subseries of Internet Requests for Comment (RFC). When a protocol is defined by both an RFC and an STD, the STD nomenclature is used.

STD-5 Internet Protocol (IP), Internet Control Message Protocol (ICMP), and Internet Group Management Protocol (IGMP)

STD-7 Transmission Control Protocol

STD-8 TELNET Protocol Specification

STD-9 File Transfer Protocol

STD-36 Interface between FDDI and IP

STD-41 and STD 43 Interface between Ethernet and IP

RFC 1441-1452 A Simple Network Management Protocol Version 2 (SNMPv2)

STD-16 Structure of Management Information (SMI)

STD-17 Management of Information Base (MIB) for Network Management of TCP/IP-Based Internets: MIB-II

RFC 1390 Transmission of IP and ARP over FDDI networks

RFC-1577 Transport of IP packets via ATM Adaptation Layer (AAL5)

RFC 1661 Point-to-Point Protocol

TBD Large Frame Size for TCP/IP

2.8 NIST Implementation Agreements

NIST 500-162 Stable Implementation Agreements for Open Systems Interconnection Protocols, Version 2, Edition 1, Dec 1988

NIST SP 500-210 NIST Application Portability Profile

2.9 Applicability of Standards

The following chart describes the CIGSS Standards Profile.

Figure 2-1. CIGSS Standards Profile

3. ARCHITECTURAL FEATURES

a. The CIGSS must operate in a multi-protocol environment to accept data from various sensors, take advantage of available communications, and exact the most capability from limited resources. During the transition period before new CIGSS acquisitions begin, bridges, routers, or gateways may be needed to achieve interconnectivity with legacy and proprietary systems. The architectural features of the airborne reconnaissance system will vary as systems are modified to migrate towards a common interoperable baseline. As new CIGSS compliant acquisitions are developed, the architectural features will stabilize. The result will be an inventory of major components within the military services that can be reallocated and reconfigured in the field to meet Joint Task Force missions.

b. All CIGSS acquisitions shall conform to standards profiles developed under the United States Imagery System (USIS) 2000. This handbook assists conformance to USIS 2000 by standardizing CIGSS component nomenclature, establishing the correspondence between the USIS 2000 architectural elements and the components and subsystems of a CIGSS, and identifying interfaces where standards are required. This approach will facilitate migration towards full interoperability and provide the guidance needed for the acquisition of a USIS compliant generation of CIGSS.

c. The Airborne Reconnaissance Technical Architecture Program Plan provides an example CIGSS Standards Profile. That profile is based upon the POSIX Open Systems Environment model which consists of applications, application platforms, and external entities that exchange information by requesting and receiving services through standardized Application Program Interfaces (APIs) and External Entity Interfaces (EEI). The common support applications request and receive system, human-computer interface, information, and communications services from the platform. External entities interface with the application platform and exchange human-computer interface, information, and communications services. Security, network management, distributed computing, and objects are cross application platform services.

d. The OSI and DoDIIS models provide a trail through the web of standards documentation, but neither is as useful as the USIS 2000 architectural description or the Joint Operational Requirements Document in establishing the functional and performance requirements needed to engineer a CIGSS.

e. The objective CIGSS architecture provides for plug and play compatibility. This means that additional components and modules brought in to augment an imagery ground or surface system capability should only require power and signal line connections to become operative. Network management software would accomplish reconfiguration automatically whether the signal connection is to the main LAN directly or through a bridge to a subnetwork.

f. In the objective system, data resides on one or more servers accessible via on-site and remote workstations. Data is either public or private. Remote users can access public data from any supporting CIGSS by dial-up over secure communications networks (e.g., TACO-2, SLIP/PPP) or via secure communications networks (e.g., DSNET 1/SIPRNET, DSNET 3/JWICS), or NIS to NIS secure communications. The minimum required connectivity for interoperability are the availability of TACO-2, and either SIPRNET or JWICS (depending upon operational security requirements). Where required, CIGSS includes crypto and multi-level secure networks.

g. It is intended that data stored at each in-theater CIGSS will be tailored to local missions, thereby reducing the complexity and cost of archival elements. The data stored in local archives may consist of images reconstructed from synthetic aperture radar, multi-spectral, visible light or infrared sensors on airborne and space platforms; digitized video from tactical airborne reconnaissance systems; reports and messages; exploitation products; and reference data. CIGSS will strictly adhere to the standardized data structures in the SPIA to facilitate remote query and minimize the bandwidth required of DSNET and tactical communications. When CIGSS uses tape based data storage units for archival and other storage requirements, it will consist of the standard formats selected from section 2 to reduce costs and enable library interchange at the media level where required.

h. When the CIGSS configuration includes a NIS, it acts as a gateway to disseminate theater collected imagery to other CIGSS. Theater collected imagery data is first formatted by the CIP into the NITF or TFRD (for interoperability) formats and sent compressed or uncompressed (in compliance with S2025A and S2025P) to the NIS. The CIP processed data may also be sent first to the IPA and then sent to the NIS for dissemination. The NIS dissemination provides one and two-way (FY96) communications at data rates of 384 Kbps to 6.176 Mbps (to be increased to 45 Mbps and higher in 1997). The NIS must, as a minimum, be able to support NITF formatted files and will support other formats, such as TFRD, only through the transition period ending in 1997.

3.1 USIS Architectural Elements

a. The USIS elements (Collection, Processing, Exploitation, Dissemination, Archive, Management, Site Infrastructure, and Global Communications) are the building blocks of the technical architecture. These elements are defined in terms of the services they provide, the interfaces they support, and their performance. The interfaces describe the points at which interoperability is achieved through standards.

b. The distinctive feature of USIS 2000 is its independence from fielded systems. Unlike a traditional architectural view which describes the connectivity between specific systems and types of equipment, USIS 2000 describes an architecture based upon an arbitrary collection of systems and components that communicate, provide services and exchange information in prescribed ways. How many systems are fielded and where these systems are located relative to one another establish capability and utility, but are not valid architectural descriptors since resources can be modified or added wherever needed without changing the underlying architecture or interrupting the ability the transfer information. Only when the interfaces between elements are changed is the baseline architecture affected.

c. The idea behind the USIS 2000 is analogous to the plug and play convenience of the internet. The internet is a collection of disparate equipment of varying capabilities at fixed and mobile locations. The equipment and its locations are constantly in flux; however, new technologies such as cellular connectivity and personal digital assistants are added with relative ease. No one can accurately list all the equipment that exists around the world, nor construct a comprehensible wiring diagram to describe its architecture. Despite this seemingly chaotic situation, the internet has an architectural stability that can be described in terms of standards specifying the protocol stack and data structures required to communicate and transfer information. The USIS 2000, like the internet, is system-independent; the key to plug and play interoperability.

d. CIGSS is an implementation of a USIS-compliant system. As shown in Figure 2, CIGSS components adhere to both the USIS architectural elements and the OSI model. The interfaces between CIGSS components are controlled by the standards reflected in this handbook. These standards are largely those prescribed by the USIS 2000. An alternative view was described in Section 2 which depicts CIGSS in terms of the POSIX reference model.

3.2 Collection Element

The collection element acquires data and transfers the incoming data stream to the processing element or to the site infrastructure element. The collection element provides imagery and data acquisition, temporary storage, support data, and management services. The collection element applications include the services that capture real-time data on tape recorders for subsequent replay through reproducers.

3.2.1 Collection Element Services

a. Imagery and data acquisition services communicate with the incoming data link, receive, detect, and control the flow of data to the processing element. The Collection Element Services are distributed between the collection sensor and platform, the link to the ground station and the data link receiver, the acquisition modules within the CIP, and the NIS gateway. The collection element includes the applications that service the data link receiver, CIP acquisition modules, the NIS gateway, and the interface device for the CDL to FDDI link.

b. Support data services preserve information needed for subsequent processing and exploitation (e.g., time of collection, position of the collector, sensor mode of operation, sensor calibration). Support data services format this data according to the sensor specific support data extensions to the NITF.

c. Management services monitor the status of the collection element with respect to scheduling and satisfaction of collection requirements; route and format command and control information to the platform. Management services also ensure that unprocessed imagery and support data is properly routed to the digital processing element.

d. The collection element services provide functions such as:

3.2.2 Collection Element Interfaces

a. There are two controlled collection element interfaces: the first, between the data link receiver (collection element) and the acquisition module (processing element); and the second, between the data link receiver (collection element) and the CIGSS local area network (site infrastructure element). The minimum standards associated with the collection element to processing element interface are: the Common Data Link (CDL); Common High Bandwidth Data Link (CHBDL, a CDL variant); and, RS-170 (composite video). Some CIGSS missions may also require interfacing with data links to receive Landsat, SPOT, EOS or other commercial satellite sources of imagery. The standard collection element to site infrastructure element interface is the CDL to FDDI interface. The CDL program is currently developing an implementation of this interface.

b. In addition to the minimum collection element to processing element standards, some CIGSS installations require processed national imagery received through a gateway to the National Input Segment. The NIS gateway also serves to provide the NIC infrastructure with imagery from CIGSS systems. The NIS is a scalable and configurable stand-alone system designed to order, exploit, archive, and disseminate NIC imagery in accordance with the USIS 2000 vision. While the NIS includes most of the functions of all USIS elements except the collection element; in the context of the CIGSS, it serves as a data link transceiver which connects to the CIGSS LAN and enables the duplex transfer of data. When a NIS gateway is required, the collection element to site infrastructure element interface includes the TFRD, S2025A and S2025P standards (until the transition to NITFS 2.0 is completed).

c. The NIS reprocesses data it receives to different compression ratios using the DCT, DPCM, and (in the future) the 12 bit JPEG algorithms, and the TFRD and NITF 2.0 imagery formats as requested by the user. The NIS provides specialized imagery processing to maximize the image quality and interpretability of the data disseminated to ultra high-resolution hardcopy reconstruction units. The NIS provides support data generation and management services, and continuously accepts new and updated processing requirements from the CIGSS. This allows delivery of near-original quality imagery from national sources in near-real time for analysis and exploitation at the CIGSS.

3.3 Processing Element

a. The primary CIGSS processing element is the CIP. The CIP may itself be a distributed processor operating over its own internal network or bus. The specific implementation method is a design prerogative. The CIP provides the services through which the data from the collection elements are reconstructed into imagery pixels, enhanced, purged of anomalies, and sent via a local area network to the archive and exploitation workstations. All exploitable imagery sent over the LAN shall use the NITFS 2.0 file format.

b. The CIP, through its acquisition modules, will accept all current sensor specific data streams, file formats, and tape based sensor recordings; and, encode the imagery in the NITF format with appropriate data extensions for dissemination to users or storage in the Archive element. The replaceable acquisition module includes the physical connector required to connect to the data link receiver (or its equivalent) and the recording subsystems, and to the hardware and software needed to detect, demodulate, and form the data sent to the processing element. Acquisition modules connect the CIP to each of the recorder subsystems or data links, demodulate the data from the incoming signal, form a baseband data stream for subsequent processing within the CIP, and transfer the data to a mass storage device (see para 3.7.4) for real-time capture when required.

c. The acquisition modules may be tightly coupled to the central processing units within the CIP, but should be replaceable. The interface between the acquisition modules and the CPU is a designer choice to provide the flexibility to achieve the required performance. Making the acquisition modules replaceable CIP components minimizes the impact that changes to the data stream characteristics for one sensor type will have on the CIP as a whole. Adding the capability to acquire a new sensor in a CIGSS, requires either (1) new software to drive an existing acquisition module; (2) a new acquisition module and new software drivers; or (3) a new acquisition module with embedded software. Existing sensor systems interface with CDL, CHBDL, RS-170, and CDL-to-FDDI links. In addition, some CIGSS missions will require interfacing with Landsat, SPOT, EOS or other commercial satellite sources of imagery. Existing recorder interfaces include the DCRSi and ANSI ID-1 formats. In migrating towards the CIGSS baseline, the strategies for accommodating existing sensors will vary.

3.3.1 Processing Element Services

a. The CIP operates on the data stream according to a prescribed set of algorithms to produce a radiance corrected image with support data extensions in NITF 2.0 format. The services provided by the CIP in the creation of the processed imagery include format conversion; compression and decompression; transformations and filtering; and removal of anomalies. Format conversion, compression and decompression, transformations and filtering are services provided by a dissemination element application resident in the CIP. The CIP also provides support data services that preserve information about the image that is needed for exploitation, archiving, dissemination, and transfer of the processed imagery in allowable standard forms and formats. The resultant image is transferred to local storage media (if private data) or to the archive element for storage and on-line retrieval. To clarify the role of processing element, the term processing is limited to those functions needed to convert imagery data into a scene contiguous pixel format. All other operations with the pixels are considered image analysis. Applications to accomplish image analysis are distributed among the exploitation elements. It should also be noted, that compression is a dissemination element function within the USIS 2000 architecture. Applications to compress an image prior to being sent over the LAN will reside in the CIP and the NIS; consequently, these components, while serving primarily as a processing and collection element respectively, necessarily incorporate selected attributes of the dissemination element.

b. The CIP provides management services that maintain track of and describe the status of scheduling and the completion of processing for each requirement. This information is provided to the CIGSS management element.

3.3.2 Processing Element Interfaces

a. The CIP interfaces with the collection element, dissemination element, and management element via local area network(s) (a site infrastructure element). The CIP receives unprocessed imagery from the collection element and transfers processed imagery to the dissemination element which controls the flow of data via a local area network to the archive and exploitation elements, and creates reduced resolution sets (R-Sets). The applications within the CIP include sensor specific processing algorithms which interface with the collection element, the National Imagery Transmission Format Standard (NITFS) file format and compression methods, and the dissemination element applications necessary to organize the data stream according to the protocol defined by the selected LAN technology.

b. The NITF is available from the CIO in a software application called SENDS. SENDS is a sample implementation of the NITFS in software that provides an example of an NITFS software engine. The current version of SENDS does not support the Support Data Extensions needed to characterize imagery from various sensors. A new version, SENDS++ is under development. The NITFS documentation (paragraph 2.2) includes the NITF file format, several compression algorithms, and a communications protocol (TACO 2). Imagery may be stored or transmitted uncompressed if required; however, each CIGSS shall include the capability to use the compression methods specified in the NITFS in addition to any mission specific methods required by the user. As a minimum, each CIGSS supports the 12 bit JPEG and Vector Quantization (VQ) compression algorithms of NITFS 2.0. The JPEG compression is used primarily for imagery while the VQ compression is primarily used by the Defense Mapping Agency for its imagery and map-based products.

c. The NIS communicates with other CIGSS components across an FDDI local area network using TCP/IP and FTP. Starting in late 1996, the NIS plans to support a HiPPI link to high performance softcopy systems using the HiPPI framing protocol or TCP/IP. The current operational NIC infrastructure uses the digital cosine transform (DCT) and digital pulse code modulation (DPCM) algorithms as defined in S2025A and S2025P TFRDs. Also supported is the NITF 2.0 format with SDE v1.0 (10 June 1994 w/Oct 94 change letter), TCS-037-028/94, and the NIC 12 bit Joint Photographic Experts Group (JPEG) algorithm as defined in S2035. The JPEG algorithm will be implemented across the NIC starting in 1997. To ensure interoperability with operational systems, the CIP will have the capability to send NITF 2.0 formatted and uncompressed or JPEG compressed data to the NIS. When required, the NIS will reformat and compress the imagery using the DCT algorithm and the TFRD format prior to storage or dissemination via the NIS. By using the inherent capabilities of the NIS to handle the TFRD (DCT and DPCM) and NITF (12 bit JPEG), the CIP design can be simplified to support only the NITF/JPEG combination while remaining interoperable with existing systems. The functionality of sensor specific algorithms are described later, as are the standards associated with cross-platform software development.

3.4 Dissemination Elements

a. The dissemination elements within the USIS Architecture are applications, including encryption, which manage the flow of imagery and imagery product information between data source and data recipient. The CIGSS dissemination element services are provided by the IESS, IPA, and NIS. The IESS provides data format, media, and queue management, as well as imagery support data processing. The IPA provides the staging of products for dissemination. The NIS provides the ability to disseminate imagery and support data, as well as provides a Back-Up Dissemination (BUD) capability in instances where connectivity between IESS and NIS is disrupted.

b. Magnetic media, including removable disk packs and standard format magnetic tapes can be used as a distribution element. All data and imagery provided in NITF compliant format shall be transferable to or from CIGSS via LCM (preferred) or high performance media if required. Existing non-standard recording systems will be tolerated until these are updated to CIGSS compliance in accordance with the standards in this handbook.

3.4.1 Data Flow Services

a. Data flow services ensure delivery between source and destination. The data flow services are provided by software applications which rearrange data (e.g., packet formation), assign delivery priorities, apply error correction, and manage routing.

b. Each CIGSS shall be capable of being both a data source and a data recipient to support the flow of imagery, imagery products and related intelligence within USIS 2000. The data flow services are specified in the Standards Profile for Imagery Distribution and are provided by NITFS 2.0 compliant software applications. Within CIGSS, most components are similarly capable of being both a source or recipient. At any point in time, the sources and recipients of data depend upon the process that is running. For example, if the data is being sent to the archive, then the CIP would be the source of the data and the archive its recipient. When an analyst retrieves imagery from the archive, the source of the data is the archive and its recipient is the analyst's workstation.

c. The CIGSS Dissemination Element has a communications interface with the Site Infrastructure and application interfaces with the Processing, Archive, Exploitation, and Management Elements. Dissemination is implemented in software through a DoDIIS profile compliant stack, as specified below. The CIGSS Dissemination Element's access to Global Communications is through interface units that are part of the Site Infrastructure. These interface units provide the necessary handshaking, and protocol translation to provide data at baseband to the global communications device.

3.4.1.1 Network Services

The CIGSS shall be accessible from a remote location (e.g., another CIGSS local area network); consequently, the protocols for connecting and transferring data from a remote facility to a primary network must be standardized. Due to its widespread use and the availability of software, CIGSS uses the MIL-STD-1778 Transmission Control Protocol (TCP) in conjunction with the MIL-STD-1777 Internet Protocol (IP) and MIL-STD-1780 File Transfer Protocol (FTP) when transferring data between networks (e.g. DISN). These military standards will be replaced by MIL-STD-2045-14502 (parts 1 through 6) which was approved in July 1994 and is awaiting release for publication. On other dissemination links, CIGSS shall use the tactical military protocol, TACO-2, specified within the NITFS. Historically, TACO-2 was developed for the point-to-point and point-to-multipoint links of tactical radio circuits where DISN was unavailable. CIGSS to CIGSS communication via the NIS is handled via TCP/IP/FTP.

3.4.1.2 TCP

a. TCP is a library of routines that is responsible for ensuring that commands sent from one end of the link get to the other end. TCP accounts for what is sent and if an element of the transmission does not reach the other end, it automatically retransmits the affected part. TCP knows nothing about the data and assumes little about the underlying communications system; consequently, TCP can be used with various packet delivery systems including the IP datagram delivery system, dial-up telephones, local area networks, and long haul radio communications. TCP does however require full-duplex communications; consequently, it cannot be used over many tactical dissemination links.

b. At the transmitter, TCP organizes the bit stream into a sequence of datagrams. In front of each datagram, TCP puts a header that contains the source and destination port numbers, a sequence number, checksum, and other information with which to manage the connection. TCP establishes a reliable virtual circuit which will deliver data from one end of a link to the other with a very high probability of success.

3.4.1.3 IP

a. The IP level is concerned with routing the datagram to the internet-like address of the destination computer. IP can be used with connectionless or connection-oriented services. A connection-oriented service is one that requires the exchange of messages to establish a connection, while a connectionless service does not. Connection-oriented services incur greater overhead; consequently, connection-oriented services transfer information at a slower rate than connectionless services operating at the same data rate.

b. IP places a header with a separate checksum in front of each datagram. The IP header also contains both the source and destination addresses, and fields to track datagrams that have been fragmented because the network cannot handle their length. This feature enables datagrams to be routed independently; consequently, datagrams can be routed around areas of the network that become unavailable due to congestion or outage (assuming of course such alternative pathways exist).

3.4.1.4 TACO-2

a. Although the tactical military protocol TACO-2 is a Military Standard, it is a profile derived from internet RFCs and ISO standards: NETBLT (RFC 998), IP (RFC 791), ICMP (RFC 792), SLIP (RFC 1055), and HDLC (ISO 3309), combined with robust Forward Error Correction. It was developed for efficient operation over simplex or disadvantaged (noisy) links where other protocols either do not provide service or fail.

b. The transport layer of TACO-2 is the NETwork BLock Transfer (NETBLT) protocol. This layer controls the flow of data achieving high throughput and reliability across a wide variety of links. The data to be transmitted is first organized into buffers of fixed size (except for the last buffer). NETBLT segments the buffers into sequences of data packets. To effect flow control, at connection-time, NETBLT negotiates the highest performance values mutually attainable by both ends of the link for the parameters of packet size, buffer size, number of outstanding buffers, burst size, and burst interval. The performance differences between NETBLT and TCP based transport result from two factors: (1) NETBLT separates of congestion control from error control, whereas TCP assumes that errors are due to congestion; and, (2) NETBLT can be used on simplex, half-duplex, and duplex links, while TCP was designed for duplex operation. When an error is detected, TCP slows down while NETBLT continues transmissions at the same pre-negotiated data rate. Under a 10-5 BER ( 80 errors in a 1K x 1K image), and depending upon the type of link, TCP/IP can take two to four times as long to complete a transmission than TACO-2.

c. TACO-2 uses IP outside of its conventional internetworking environment; consequently, some components of IP are not necessary. A TACO-2 compliant receiver disregards any IP information is does not need. Another feature of TACO-2, is the availability of Forward Error Correction (FEC). The algorithms for the two effectivities, FEC-I and FEC-II, are described in MIL-STD 2045-44500 w/NOTICE 1 (29 July 1994) and this standard should be consulted for implementation details. FEC-II is the preferred algorithm for highly disturbed links (e.g., BER worse than 3x10-3); FEC-I is recommended for use when the BER is between 3x10-3 and 5x10-5.

3.4.2 Format Services

a. The dissemination element does not distinguish between internal and external addresses. External dissemination is accomplished by routing the information through the Site Infrastructure and Global Communications Elements to an address located at another site. For profiled distribution and format changes, users submit their distribution and format requirements to the Management Element, and the Management Element levies the requirement to the Dissemination and other Elements to meet users' needs. The Dissemination Element supports multiple address profiles, and will hold imagery items in queue (buffer) until the time of transmission or, until purged by operator action via the Management Element. Hardcopy distribution to the ultra high resolution unit (HRU), or advanced hardcopy unit, is done through the NIS. In the future, a hardcopy unit may contain the processing chain functions so it could interface directly to a LAN and use standard format inputs.

b. A consequence of the flexibility to send data to various devices is the need for the dissemination element to provide format services. These format services are provided at the application layer. For example, images and other files sent to printers will incorporate drivers that communicate with the device and form the appropriate data stream. Data that is to be disseminated by tape recording shall be formatted by a recording interface which is compatible with NITFS 2.0 and the standard format recording system. Similarly, in preparing data for external dissemination, an application generating a product is required to be NITFS 2.0 certified; consequently, all imagery being transferred to an interface unit for external dissemination will use the NITFS 2.0 format and compression methods (if not uncompressed). The NIS processes NITF 2.0 and NIC formats defined in the S2025A and S2025P tape format requirement documents. It should be noted that there are no rules for how imagery is stored in the Archive Element; the only requirement being that data in and out of the Archive Element be in NITF 2.0 format and may be compressed or uncompressed in compliance with the NITFS.

3.4.3 Management Services

Dissemination Element Management Services include imagery dissemination management services as well as network management services. The imagery dissemination management services as provided by IESS include the Simple Network Management Protocol (SNMPv2) (RFC 1441-1452) and guidelines associated with the Information Base for Network Management of TCP/IP-Based Internets (RFC 1213).

3.5 Archive Elements

a. The Archive Element accepts, catalogs, stores, and retrieves digital data. The Archive Element has been implemented in the Image Product Archive (IPA), a government developed, scalable suite of hardware and software intended for the long-term storage of processed imagery and imagery products. The IPA may be used in CIGSS as the Archive Element host. Archives may be distributed on the LAN or organized within a subnetwork. The exploitable imagery output from the CIP is archived according to the CIO approved standard format (USIS Standard Profile for Image Archives (SPIA)).

b. The Image Product Archive (IPA) consists of an image server, disk farm, and terminals connected through an FDDI local area network. At some CIGSS installations, the processing demands may be greater and an FDDI local area network may not be adequate (see discussion in paragraph 3.3.2 et. seq.) Temporary storage (e.g., up to 30 days) of raw data on tape may also be provided.

c. An archive element may also accompany a NIS. The NIS is required to store imagery and support data using both tape and disk media for a minimum of 7 days in the TFRD and NITF 2.0 formats, and in the compression in which it was received to reduce the effects of concatenating compression and expansion operations. These public data are accessible through directory services which support searches based upon user inquiry. The directories are automatically updated as the archive is modified. The status of the archive is provided to the management element. The IESS provides brokered cataloging of the NIS archives for the IPA server.

d. The archive element does not include the mass storage media used to store private data. These media, such as tape recorders and random access media provide for local functions such as capturing data from live feeds in real-time and on-line storage of intermediate products or work in progress. Tape recorders shall comply with commercial format standards if selected to be the mass storage media. These mass storage devices and associated software applications are part of the site infrastructure element.

3.5.1 Archive Element Services

a. The Archive Element services are Data Management (import, export, purge, delete, etc.), Discovery (browse, search, select, notify, etc.), and Management services. The function of data management is to accept and catalog information; segregate data in accordance with security practices and requirements; and provide a means, through interaction with the management element, to purge data stored. The discovery service enables local and remote archive users to browse through archival holdings to discover what data is available that may satisfy their needs. Archive management services provide housekeeping functions for the archive. These include checking the integrity of the media, defragmentation to maintain access time and throughput, automated backups, and data recovery.

b. The physical storage of imagery and imagery products within an archive element depends upon the technology of the media used within the archive. The media shall comply with commercial format standards for data exchange. The media, its controller and driver shall perform any necessary data reorganization so that to the user it appears that imagery is a contiguous NITFS file. The standard set of browsable data elements used to catalog imagery in the archive is defined in the USIS SPIA. All transfers of imagery and imagery products into and out from the archive shall conform to the NITFS 2.0. This enables a CIGSS to remotely browse and pull imagery and imagery products from another CIGSS, provided security access has been granted. The software to enable remote browsing shall be GFI. A CIGSS shall be capable of providing imagery products from the archive to a tape recorder interface for a standard recorder format.

3.5.2 Archive Element Interfaces

The Archive Element is a software application; consequently, its interface with other software applications is defined by an API. That API is under construction by the CIO. The Archive Element is hosted on workstations which belong to the CIGSS Site Infrastructure. The Archive Element can send and receive the NITFS 2.0 file format; however, there is no restriction on how the information is stored.

3.5.3 Image Product Archive

a. The Image Product Archive (IPA) is under development to provide community users with a scalable subsystem for the storage, query, response, request, and transfer of imagery products and unexploited (raw) imagery at various commercial LAN rates. An installation of the Archive Element resides within the IPA.

b. The IPA uses a client server architecture. The IPA components may be incorporated into a CIGSS FDDI LAN or used on an FDDI subnetwork to the main CIGSS network. The standard IPA also includes IESS and National Dissemination System (NDS) interfaces specifically to support the query and transfer of images from IDEX workstations and includes an IESS interface to support the query and transfer of imagery from the NIS. The IPA provides the capability to operate in either the DoD collateral (DSNET 1/SIPRNET) or SCI (DSNET 3/JWICS) security environments. Operation of the IPA in a collateral DSNET 1/SIPRNET environment with IESS at SCI requires multi-level security.

c. The IPA server software application contains the image/product library and its directory, and a client application to support X-terminals. The IPA software is GFI; however, the current application has not been developed as an open architecture. The IPA supports NITF 1.1 and 2.0. NITF 1.1 ensures backward compatibility with older Secondary Imagery Dissemination (SID) devices. By DoD directive, all new SIDs acquisitions will conform to NITFS 2.0. It is the intent of this handbook that CIGSS shall remain compliant with the NITFS as that standard evolves.

d. The production IPA will not support the Tagged Image File Format (TIFF) which was supported during IPA pilot development. TIFF was developed by Microsoft and Aldus to store images in a machine independent way and has become a defacto standard, by virtue of its widespread use both in scanning and its import/export acceptance in commercial image analysis and enhancement applications. TIFF stores one image at a time in a tagged data block and then defines a linked list of tag blocks. This is different from the usage of headers, images and sub-images, annotations and metadata within the NITF format. For example, TIFF does not support annotations without overwriting the underlying information; consequently, it shall not be used for imagery products and overlays disseminated over secondary channels. If used within a CIGSS to support scanning and digitization of film products, TIFF shall only be used for local products. The CIO can provide TIFF 6.0 to NITFS 2.0 translation software for use in CIGSS applications.

e. The production IPA will also not support the Sun Raster format which was supported during IPA pilot development. This does not preclude a CIGSS developer from translating among proprietary formats to make efficient use of the internal architecture of a specific application platform; however, no proprietary raster or image file formats shall be used for archival storage or dissemination.

f. The IPA client software both pulls images from the server and pushes products and metadata onto the server. The metadata is specific to the NITFS; i.e., the NITF header and tagged extensions. The IPA client software is planned to be integrated with JDISS, CAWS, and Intelink so that these workstations may be used as clients within the IPA environment. The API is GFI.

3.6 Management Element

a. The management element is distributed over all other elements to provide nominations, repository, delivery, and executive management services for coordinating all CIGSS activities. The management element also provides services, as needed, for mission, navigation, sensor, communications planning and control functions. The management element allocates resources, controls data flow, and manages the storage and retrieval of imagery information across the USIS. Within the CIGSS, the management element interfaces with each of the other architectural elements; consequently, the management element is embedded in the cross application platform services of security, network management, distributed computing, and objects management.

b. Security services include authentication, access control, data integrity, data confidentiality, non-repudiation, and availability. These shall be provided by software certified and approved by the cognizant security agency for the level required. Network management services include configuration management, performance management, fault management, accounting management, and network security.

c. Repository management services provide responses to user queries concerning the status of items stored. Delivery management services include adaptive data rate selection to accommodate changes in the communications channels. Executive management services provide for the overall coordination of management functions. These functions are distributed among CIGSS elements, including the NIS, as required by the design.

d. Exploitation requirements management, imagery dissemination management, hardcopy/softcopy exploitation task management, and host database management as provided by the IESS.

3.6.1 Nominations Management Services

a. Nominations management services provide the coordination necessary to accept user requirements for new information; aggregate, assign, and prioritize these requirements; and track requirement satisfaction. These services are accomplished by the Imagery Exploitation Support System (IESS), Joint Collection Management Tool (JCMT), and Requirements Management System (RMS) GOTS software applications.

b. The support tool used in the objective CIGSS to manage national dissemination and exploitation and identify relevant historical data is the Imagery Exploitation Support System (IESS). This tool is not used in current Navy imagery systems afloat. The IESS is the follow-on to the Computer-Aided Tactical Information System (CATIS). A version of this application for JSIPS supports the management of tactical inputs (e.g., ASARS).

c. The collection manager determines, based upon knowledge of and availability of resources, what assets are best able to provide the data to satisfy each requirement. Information from several disciplines may be required and within each discipline specific platform and sensor technologies need to be selected. The JCMT and the projected (e.g., late 1995) RMS are the applications used to support the collection manager in these activities. RMS is not planned to be used in current Navy imagery systems afloat. The RMS generated messages are dispatched for approval and subsequent collection and exploitation tasking. The schedule of operations is then translated into platform and sensor commands. The extent of collection management and platform control functions required at each CIGSS will vary with mission requirements. Each CIGSS utilizes IESS to respond to RMS exploitation tasking. CIGSS that will task and manage sensor systems (e.g., ASARS-2) will require sensor management functions that respond to RMS tasking. In addition, IESS also provides the capability to generate Imagery Information Need (IIN) data.

3.6.2 COTS and GOTS Support Software

a. Support software is needed to prepare and manage the flow of data required for CIGSS operations. This software includes commercially available word processors, spreadsheets, databases, communications tools, productivity and personal information managers (e.g., calendars, note pads). If the communications application provides the NITFS 2.0 compliant TACO-2 protocol, then a separate TACO-2 GOTS application may not be needed. Each acquisition authority shall determine which COTS support applications to fund based upon user requirements. Acquisition authorities are encouraged to find and integrate COTS solutions where GOTS software is unavailable, and to ensure that applications provided to the community are transportable to open systems hardware.

b. Other support software for managing the flow of data and operations of peripheral equipment such as scanners, hard or removable drives, CD-ROM drives, digital cameras, and data recorders, are ordinarily supplied with the item. Requirements for these will vary with each CIGSS acquisition.

3.6.3 Operating System

Operating systems used within CIGSS shall be compliant with the Portable Operating System Interface for Computer Environments (POSIX). Acquisition authorities shall determine the most current version of each part of the standard. Those that apply to CIGSS are:

The Ada Language Binding (POSIX.5), System Administration part (POSIX.7), and Transaction Processing (POSIX.11) are optional.

3.6.4 Mission Planning and Control Functions

Operational mission planning and control functions may be required for some CIGSS installations. Mission planning and control applications and workstations will be required to implement these functions.

3.7 Site Infrastructure Elements

a. The site infrastructure elements provide the computer and communications services for all other architectural elements within the site and any gateway that connects the site to other sites through the global communications element. The CIGSS site infrastructure components include the workstations, operating systems, storage devices, recorders, printers, and the local area network fiber plant. Given sufficient computational power, communications bandwidth, and temporary storage capacity (e.g., RAM and digital recording), the site infrastructure elements can support any type of imagery.

b. The site infrastructure also provides the interfaces and resources to enable users at the site to share and transfer data. This is accomplished within CIGSS by the local area network. The LAN includes aspects of both the site infrastructure and dissemination elements.

3.7.1 Physical Layer Connections

The physical layer specifies the mechanical and electrical properties of the signal interface, the functions that are performed at the interface between the system and transmission medium, and the sequence of events that need to occur for bits to be transferred. The tape media and format is also defined for data transfer. Various physical connections are used in the CIGSS. These connections and associated protocols are specified in the interface standards.

3.7.2 Opto-Mechanical

a. All high speed network connections shall employ multi-mode 62.5/125 micron fiber optic cables and support 1300 nanometers (nm) optical sources. The attenuation of fiber is lowest at 850 nm, 1300 nm, and 1550 nm. The use of 1300 nm is optimal since the chromatic dispersion is lowest at that wavelength; also 1550 nm requires a laser diode rather than an LED or super-luminescent LED. Fibers shall conform to EIA-455-48 (core), EIA-455-27 or EIA-455-48 (cladding), and EIA-455-57 (aperture). Fiber selection shall be based upon the optical power, channel bandwidth, and distance requirements for each CIGSS. The 62.5/125 micron size should be used whenever possible since it is the defacto-standard in the US with a large installed plant base. The connectors shall be of the fixed shroud duplex (FSD) type in conformance with the FDDI Physical Medium Dependent (PMD) specification.

b. Low speed ethernet LANs shall be designed for 850 nm sources and use bayonet type ST connectors with a maximum insertion loss of 1.0 dB and a standard deviation not to exceed ±0.15 dB. Panel mounted connectors shall be female and equipment cable ends male. The ST connector aligns the fiber ends via straight ceramic tips which slide into a sleeve contained within a metallic barrel coupler. The ST connector offers the lowest typical loss of the three leading fiber-optic connector types and has been selected because of its availability, durability, and performance.

c. All optical interface units shall be internally mounted or bolted to a component cabinet so that the component and its interface, when casually moved, remain an integrated unit.

3.7.3 Electrical

Each CIGSS transportable component shall include an internal power supply capable of operating off of the following nominal single phase ac line voltage ranges: 100V (88-110V), 117V (103-128V), 127V (112-128V), 220V (193-242V), 240V (211-264V) at 47.5 to 63 Hz. Power conditioning and quality shall conform to MIL STD 704.

3.7.4 Mass Storage

a. Mass storage devices (e.g., tape, hard disks, RAID arrays, ZIP drives, magneto-optical disks, CD-ROM etc.) are normally used to retain data for subsequent retrieval. The site infrastructure elements, through the use of technology dependent media driver software applications, manage the formatting and transfer of data to and from mass storage devices. In the USIS 2000 architecture, an archive element always manages public data; that is, data, indexed for remote access. Both the archive element and the site infrastructure element may also manage and retain private data. Private data differs from public data in that it is only accessible through the workstations and other computing devices with which it is networked. Private data may be stored in any format most useful for the CIGSS mission.

b. Since there are no requirements for the exchange of private data; the choice of mass storage technology used solely for private data is a prerogative of the CIGSS program office. To ensure interoperability for the remote access and dissemination of public data, mass storage devices and associated archival applications are required to conform to the CIO Standards Profile for Imagery Archives and Standards Profile for Imagery Dissemination. When tape is used for remote access and dissemination it shall comply with commercial tape format standards.

c. Mass storage devices interface with site infrastructure elements (e.g., workstations and servers) or with the dissemination element (LAN). The configuration of mass storage is a design issue, and interfaces shall conform either to the requirements of the selected LAN technology if intended to be connected to the LAN directly, or employ the SCSI-2 commercial standard if separable from the workstation or server.

d. Data from some sensors are routinely stored on magnetic tape and operations require the ability to import data from these media. The CIGSS program office shall determine if such capabilities are required by the facility mission and provide the required hardware and software.

e. Imagery products may be stored compressed or uncompressed according to local mission requirements. Examples of mission specific storage requirements include national imagery. In the case of CIGSS having a requirement to store national imagery for subsequent distribution, the community standard DCT, and DPCM compression algorithms will be used for storing the raw imagery until phased out starting in 1997. The government will furnish the CIGSS developer with the software application for compressing and decompressing this imagery at the softcopy workstations.

f. Some CIGSS applications will require use of stored imagery sensor data from digital tape recorders designed to conform to ANSI ID-1 format and the Ampex DCRSi format. These tape recorders interface with processing elements and the global communications elements. Software to write and read these tapes is GFI. The API is provided in IRIG Standard 106-93. These tape recorders shall be interfaced and controlled to provide recording of live link data. The recorders shall be capable of replaying raw imagery sensor data.

3.7.5 Workstations

a. Workstation access is required for network management; collection, requirements, and exploitation management; archival inquiry and processing; image processing and analysis; preparing and sending reports and other imagery based products; and managing communications and other gateways. These functions are expressed through platform independent applications. CIGSS imagery analyst workstations will be used for softcopy imagery exploitation, as well as access to the IESS, archive element, and the RMS (when applicable).

b. All workstations that may be deployed to augment another CIGSS site shall support IEEE 802.3 and FDDI network connectivity via fiber optic links, unless as a result of using higher speed connectivity than FDDI for normal operations (e.g., HiPPI, ATM), do not have expansion slots to support both ethernet and FDDI ports. In these cases, the acquiring program office may include either an ethernet or an FDDI port. Workstations shall also have an RS-232 serial, SCSI-2 and Centronics parallel ports to facilitate the connection of common peripherals. Workstations may be COTS or GOTS.

3.7.6 Reference Databases

Reference databases and associated storage media enable the storage and retrieval of information needed by analysts to exploit imagery, fuse imagery with other intelligence, generate imagery products, and prepare narrative intelligence reports. Information in reference databases is mission dependent.

3.7.7 Local Area Networks and High Speed Switching

a. The selection of a network or switching technology drives the acquisition cost of all components; consequently, only standard, commercially available networking technologies shall be considered for CIGSS acquisition. Proprietary local area networks, switching devices, and special purpose busses to interconnect site infrastructure elements are not allowed. Proprietary interconnections may be used at the circuit board level or subassembly level only if the interconnection does not cross a standard interface as specified herein. Program offices having fielded systems using proprietary networks, switches, and special purpose busses should provide DARO with cost estimates and impacts to migrate these to the standards described herein.

b. Consideration must be given to both external and internal connectivity requirements. Externally, CIGSS is required to interconnect with broadband services offered by military and commercial SATCOM such as the DoD DSNET for secure long-haul transmissions; tactical networks, and tactical radios for secure broadcast and point to point secondary dissemination; and, in the future with wide-area, fiber-optic ATM networks operated by the military and commercial telecommunications companies.

c. The CIGSS can have one or more local area networks or switches for internal control of imagery and data. For example, a CIGSS may combine a high data rate LAN as an internal backbone for input processing and real-time storage with lower speed LAN subnetworks for imagery exploitation and management control. Interoperability is achieved by standardizing the LAN interfaces used to interconnect site infrastructure elements, using the file format and compression methods specified in the NITFS 2.0 to transfer imagery, and requiring the use of applications that support the open systems interconnect model and which are NITFS 2.0 certified.

d. Each CIGSS workstation and separable component that may be deployed from one CIGSS to augment another (e.g., an exploitation suite, Image Product Archive) shall provide ethernet and FDDI connectivity. This is to ensure that it is possible to operate these components when deployed from one system to another to meet military exigencies. For example, an exploitation workstation operating in an FDDI configuration could be moved to another CIGSS and connected either via its ethernet or FDDI port.

e. Whenever different LANs are bridged, there may be a performance degradation. In the case of short frames, the performance hit on an FDDI LAN in bridging between Ethernet and FDDI LANs can reach 50%; however, in the case of long frames, the performance would be much better. FDDI's primary benefit is its inherent redundancy and the ability to move to ATM/SONET over the same FO cable.

f. There are several migration strategies to move among the ethernet, FDDI, and ATM technologies. A near term solution, currently in vogue in the corporate world, is the use of intelligent hubs (switches and routers) that service clients at backplane throughputs between 10 Mbps and 32 Gbps. An FDDI ring interconnects the hubs and since the hubs handle the switching to and from subnetworks, the main network is relieved of considerable congestion. A representative sampling of 34 products from 18 manufacturers shows that all 34 support ethernet connectivity, 16 switches support FDDI, and 6 currently support ATM.

g. Internally, the selection of a network or switching technology depends primarily upon the technical requirements for moving data between workstations and archives to satisfy the user mission profile. The acceptable technologies for CIGSS are:

h. The choice of network or switching technology requires an analysis of the missions to be conducted at that facility and the known and projected workload. The key consideration is the ability to interoperate with the USIS architecture. The primary factors in achieving this interoperability are compatible cryptographic equipment, compatible global communications, common tape formats, and compatible file formats and protocols.

i. In selecting a technology, the number of workstations and peripherals on the network is of critical importance. It is entirely possible for an ethernet LAN to outperform an FDDI network because the ethernet switches can deliver dedicated data rates (nominal 10 Mbps) to each workstation and server while the FDDI bandwidth (100 Mbps) will be shared (dynamically reallocated) by all users.

j. Each CIGSS has the requirement for transferring both control data and imagery over its internal network. Control data may be moved over the same or a separate LAN from imagery data.

k. The long-term goal for CIGSS is to migrate towards ATM transport over a SONET network. This is the only technology that offers expandable high bandwidth commercial service. ATM is not yet considered a mature technology because software signaling standards among ATM switch manufacturers are still under development. Incompatibilities exist among switches from different manufacturers that result in interoperability problems for features such as switched virtual circuits and route negotiation. The situation is expected to self-correct as market pressures for broadband services shake-out the industry in the near term and force interoperability. Switches are currently compatible at the media/timing level, and permanent virtual circuits are supported between vendors.

l. At the national level, ATM will be used well into the next century. The initial phase of the ATM backbone for the intelligence community is operating with the remaining installation underway. ATM has been installed and is operational at the desktop of several officials, though most users are connected to the backbone through legacy networks. The success with ATM has led to the decision to gradually extend ATM to each desktop on that network. Although CIGSS must operate within the context of a broad range of missions and environments, the national military and commercial experiences with ATM suggest that the stabilization, standardization, and affordability of the technology will be attained in the near term.

m. Each program office is responsible for sizing and engineering its CIGSS acquisitions. Although this handbook presumes that most CIGSS would operate adequately at FDDI to HiPPI data rates, ATM may be a good solution for some near-term applications. Moreover, ATM will likely be the solution of choice by the end of the decade. The handbook also addresses the potential requirement for CIGSS functionality in some very low volume, albeit exceptional instances for which an ethernet network would be sufficient.

3.7.7.1 Ethernet

a. Ethernet (IEEE 802.3) is a common commercially available network protocol. The primary application for ethernet within CIGSS would be for control data and messages; however, ethernet could support very low volume image exploitation (10 Mbps bandwidth). Fast ethernet (IEEE 802.12) provides an order of magnitude (up to 100 Mbps) more bandwidth and is generally more useful for image exploitation.

b. Ethernet is unique in that the address of each ethernet device is registered with a central authority; consequently, no two commercial ethernet controllers will have the same address. The ethernet source and destination addresses are included in a header that gets added to each datagram. The ethernet header also includes a checksum for the entire datagram, and a "type code" field that enables the ethernet controllers to work with several different protocols (e.g., TCP/IP, DECnet, etc.) over the same physical network.

3.7.7.2 High Performance Parallel Interface

a. The High Performance Parallel Interface (HiPPI) is used as a standard-channel interface and back end LAN in the supercomputer market. It provides high speed (800 Mbps) channel-to-channel interoperability among heterogeneous supercomputers and is particularly useful for the movement of large data files. A HiPPI switch moves data in one direction; however, two such simplex channels may be configured to provide a full-duplex circuit. A local area network can be constructed from at least two full-duplex HiPPI nodes. HiPPI switches have been used in two government sponsored gigabit testbeds to interconnect several supercomputers over SONET. Several supercomputers were connected to HiPPI switch nodes and the nodes interconnected by a fiber optic cable plant operating as a Synchronous Optical Network. HiPPI is a potential solution for high speed processing of imagery or for moving images within high volume exploitation cells.

b. The HiPPI protocol suite includes a physical layer, switch control, framing, and upper layer protocols. The upper layer protocols define services such as IEEE 802.2 Link Encapsulation, HiPPI mapping to the British developed Fibre-Channel, and the Intelligent Peripheral Interface.

c. The HiPPI Mechanical, Electrical, and Signaling Protocol (HiPPI-PH) defines a physical layer of 100 lines (50 twisted copper pairs) for transferring data in parallel. The copper wire cable is limited by the standard to 25 meters per segment; however, serial HiPPI, using the Fibre Channel international standard and fiber optic cable, extends 800 Mbps data transfers to 10 kilometers. Standard HiPPI is based upon a 32-bit word; there is a double wide version (64-bit words) that can achieve 1600 Mbps data transfers.

d. The HiPPI Framing Protocol (HiPPI-FP) defines a frame consisting of 1016 bytes of control information and 4 gigabytes of data. Data is transferred in bursts of 256 words (8192 bits) over the physical media. The relatively low overhead on large files makes HiPPI a convenient protocol for visualization applications.

3.7.7.3 Fiber-Distributed Data Interface

a. The Fiber-Distributed Data Interface (FDDI) and its follow-on FDDI-II carry both ANSI and ISO designations. The FDDI standard includes medium-access control (MAC) and physical layers. It supports the use of IEE 802.2 logical link control. The FDDI MACs have a token ring protocol similar to IEEE 802.5. The differences in the MAC generally are needed to support the higher data rates at which FDDI operates.

b. FDDI can be used directly as a LAN or as a backbone to interconnect lower speed LANs. An FDDI LAN operating at 100 Mbps provides a sustained data transfer rate of up to 80 Mbps. Full analog video (e.g., 6 MHz TV channel) requires 90 Mbps (uncompressed) and this would swamp an FDDI LAN. To meet the demands of broadband services such as High Definition Television (HDTV) (which requires approximately 150 Mbps per channel) FDDI II, a superset of FDDI provides the capability of transferring voice and T1-compressed video over an upward compatible fiber optic network.

c. The reliability of the FDDI ring may be enhanced by constructing a second ring in which data can be transmitted in the opposite direction. Normally the second ring is idle; however, when a link failure occurs, the stations on either side of the failure are reconfigured and the data rerouted across the second ring. This dual ring architecture is the key to the self-healing property of FDDI networks. The dual ring topology is one of four possible types, the others being: stand-alone concentrator; tree of concentrators; and a dual ring of trees.

3.7.7.4 Synchronous Optical Network/Synchronous Digital Hierarchy

a. Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) is an optical transmission medium designed to take advantage of the digital transmission capability of optical fiber. SONET is an ANSI standard and SDH is a CCITT recommendation. The SONET documentation establishes standards for multiplexing data; interconnecting equipment from different suppliers; operations, administration, and maintenance capabilities; and, accommodating future broadband applications.

b. A SONET frame (STS-1) consists of 810 octets organized into nine rows of 90 octets each transmitted once every 125 microseconds (51.84 Mbps). The SDH frame (STS-3) operates at 155.520 Mbps and supports the transport of Asynchronous Transfer Mode (ATM) cells. The effective transport rate for ATM cells is 135.632 Mbps; the remaining bandwidth being used for overhead.

3.7.7.5 Fibre Channel

Fibre Channel was developed by the British (hence the spelling of fibre) and is an international standard used to extend the data rate-distance capabilities of other high speed technologies such as HiPPI. When used with HiPPI, Fibre Channel offers the advantage of striping; that is, the transfer of data in parallel over multiple channels. The effect is to create a virtual channel with a data rate that is the aggregate of the combined single-channel bandwidths.

3.7.7.6 Technology Migration

a. The ability to migrate from lower data rate technologies such as IEEE 802.3 to faster LANs such as FDDI and HiPPI depends in part upon the physical layout of the cable plant and whether its original implementation was in fiber, coaxial cable (e.g., BNC connectors, RG 58U cable), or telephone wire (e.g., RJ-45 connectors, flat telephone cable). The CIGSS cable plant will use fiber optics with connectors as specified in 3.7.2a and 3.7.2b. This will simplify the transition to higher bandwidth technologies and ensure that components from one CIGSS can be connected to components of another CIGSS. Fiber-optic to electrical data link transceivers will be part of each CIGSS infrastructure component that interfaces with the dissemination element to ensure that when a component is moved, its transceiver is moved as an integral unit.

b. Bridges exist for interconnecting FDDI networks with IEEE 802.3 and 802.5 subnetworks. If a CIGSS uses a higher data rate technology than FDDI, it will include a bridge to enable an external FDDI facility to be connected. Issues such as the use of dual counter-rotating or single ring implementations of an FDDI backbone are within the purview of the acquisition authority. In laying out the physical plant, consideration should be given by the acquisition authority to enabling an easy transition from a dual ring FDDI network to the use of future high speed protocols.

c. Over time, most installations will need to migrate to greater bandwidths for imagery processing and exploitation. The requirement for inclusion of ethernet and FDDI connectivity for deployable components ensures the availability of a lowest common denominator interconnectivity for workstations and peripherals. The objective CIGSS will likely extend the base level for connectivity to one of the lower data rate services available within ATM. In a similar manner, exploitation subsystems that typically consist of several workstations and image archive servers may require migration from external FDDI to HiPPI, or ATM interfaces to ensure acceptable performance and interoperability when one exploitation suite is needed to collocate and interoperate with another.

3.7.7.7 Throughput and Sizing Considerations

a. Data for gauging LAN technology needs is provided below. The requirements for IR line scanners, ASARS-2, UAV SAR, and full-screen video will dominate the network data transport requirements in the near term; however, future requirements for multispectral and hyperspectral still and stereo imagery and high resolution video can be anticipated.


ASARS-2 or SAR     84 Mbps Video Phase History, 8 Mbps spot image (ASARS-2)     

                   122 Mbps (SAR). The approved ASARS-2 upgrades will increase  

                   the downlink to 274 Mbps and processed imagery to 45 Mbps.   

                   Future SYERS upgrades will increase its data rate to 274     

                   Mbps and 650 Mbps.                                           



SYERS              137 Mbps (SYERS).                                            



Primary Images     Typical 17K pixel x 17K pixel @ 11 bit/pixel: 3.33 Gbit      

                   uncompressed.                                                



IR Line Scanner    10 Mbps.                                                     



NTSC Video         Frame: 640x480 pixels                                        

                   Fields: (2) 640x240 pixels                                   

                   60 fields/sec 1.54 MB/sec at average 6:1 frame compression   

                   (B/W)                                                        



PAL Video          Frame: 768x576 pixels                                        

                   Fields: (2) 768x288 pixels                                   

                   50 fields/sec                                                

                   1.9 MB/sec at average 6:1 frame compression (B/W)            



NITFS Image        Less than 1 Megapixel to over 1.5 Gigapixel depending upon   

                   the type of product. A typical 17K pixel x 17K pixel FAF     

                   block is equivalent to 3.33 Gigabits (417 Megabytes).        

                   Typical volume 300 Gpixel/day uncompressed.                  



Text Page          1.24 KB per page, 1 page/image.                              



Line Graphic       35 KB.

b. The data indicates typical rates at which data for the ASTAMIDS/RISTA IR line scanner, ASARS-2, SAR, and SYERS would need to be transported over the LAN after initial processing.

c. The data for NTSC and PAL (e.g., European and others) video assumes an average frame compression ratio of 6:1. SECAM video, a different technology (FM/phase versus AM) from NTSC/PAL is used primarily within the CIS (former Soviet Union) and has not been included. If needed in the future, commercial hardware is available from television broadcasting industry suppliers that convert signals from one video standard to another. The 6:1 compression ratio is approximately the average level of compression obtained with MPEG2 for scenes with moderate motion; scenes with little movement may be compressible up to 50:1. CIGSS shall accept NTSC/PAL inputs and provide NTSC/PAL outputs for recording imagery. The video signals shall be digitized for transfer over the LAN.

d. In the CIGSS, large amounts of data must be transported from the CIP to an archive or local storage device. Data is then pulled from the archive or storage device by analysts for exploitation. The load offered by the processor depends upon the type of imagery being received and whether the output is continuous. The load offered by subsequent image processing and exploitation depends upon the number times the analyst retrieves or stores the image.

3.7.7.8 Selecting Feasible LAN Technologies

The following steps illustrate how to size and specify the LAN technology needed for a specific application. Estimates of steady-state throughput to within a factor of two are normally adequate for determining the feasibility of any specific LAN technology. A detailed engineering analysis of data flow and congestion is necessary to estimate performance under various offered loads.

  1. Approximate the mission profile of the CIGSS installation by estimating the amounts of image, video, and text handling that will be required.
  2. Convert amount of images, video, and text to be processed into average effective data rates. Raw data transferred directly to an archive and near real-time processed imagery should be estimated separately. The bandwidth requirements can be combined later if needed.
  3. Adjust calculated rate for growth. The growth factor should be at least 50%
  1. Add a fraction (about .3 to .4) of the peak capacity to the growth adjusted rate for interprocessor communications.
3.8 Digital Exploitation Element

a. The digital exploitation element within the CIGSS provides the information processing capabilities to manipulate, analyze, interpret, and extract information from imagery produced by the digital processing element. The digital exploitation element also provides report and product generation services. Finally, the Exploitation Element provides support for the management of exploitation resources in the service of user needs. The intelligence cycle begins with the expression of need by a user and its translation into a collection and/or exploitation requirement. Information processing requirements therefore depend upon the role of the CIGSS in the intelligence cycle.

b. Since CIGSS may be deployed at various echelons and involve sensors of significantly different capabilities, the requirements for information processing support at a particular CIGSS will vary. Digital exploitation may be distributed among different segments or different CIGSS. For example, COTS or GOTS exploitation software (e.g., MATRIX) may be hosted on the NIS and invoked at NIS workstations in support of operations. The resulting products may be disseminated directly to the CIGSS via gateway connectivity to the CIGSS LAN or sent to CIGSS via NIS to NIS or other communications means.

c. Output Products. CIGSS output products include, but are not limited to intelligence reports, images and annotated images, and graphic situation displays (GSD). The standards that apply to these products are:

d. Within the CIGSS baseline, the IESS will be the primary component for digital exploitation reporting. The IESS provides the capability for the generation and dissemination of exploitation reports, as well as performing exploitation task prioritization, task allocation, media control, quality control, dissemination control, and management of the digital exploitation environment.

3.8.1 Image Manipulation and Analysis Services

a. The image manipulation and analysis services provided by the Exploitation Element are provided by the image processing and image analysis software within the CIGSS. The imagery analyst accesses archived imagery and historical coverage files from a workstation and uses software tools resident within CIGSS to do image enhancement, mensuration and feature extraction; overlay geographic information; apply principal component and other analytical techniques; and fuse data from other disciplines to obtain the information that will answer the essential elements of information (EEI) and provide the products that the commander needs to visualize the enemy situation.

b. The distinction between image processing and image analysis is that processing converts raw data into a product that can be exploited. Analysis is the process of exploitation and can be automated, interactive, or manual. The sequence of steps needed to extract information and prepare an exploitation product depends upon the required EEI, the shapes of the objects in the scene, illumination and shadows, military and physical context, etc. Each CIGSS installation will tailor its software tools suite to accomplish its missions; consequently, each receiving CIGSS is responsible for coordinating any special software requirements it may have.

c. Image manipulation and analysis services depend upon the type of image to be processed and the types of products to be generated. Basic services include the following categories and examples: 


 Category of Service                Examples of Specific Services                



Geometric             Scaling, rotation, registration, rectification, panning,   

                      zoom.                                                      



Filters               Edge detection, anti-alias, sharpen, blur, contrast,       

                      lighten, darken, spatial domain.                           



Statistics            Correlation, histogram, image statistics.                  



Printing              Dithering, lines/angle, color/gray scale.  (These are      

                      site infrastructure elements normally invoked through      

                      commercial image analysis and enhancement software during  

                      a Print operation.)                                        



Display Generation    8-bit Gray scale, up to 24-bit color, stereo.  (These are  

                      site infrastructure elements normally invoked through      

                      commercial image analysis and enhancement software during  

                      a mode change operation.)                                  



Annotation            Text and Graphics - both NITF compliant.  (For products    

                      intended for distribution.)                                



Convolution           General kernel creation.                                   



Compression           NITFS compliant (e.g. JPEG, Vector Quantization).          

                      (Compression is a Dissemination Element function normally  

                      invoked through commercial image analysis and enhancement  

                      software as a selection during a Save operation.)          



Format Conversion     NITF for products intended for distribution.  (For         

                      internal special purposes may include others such as       

                      TIFF, Landsat/SPOT.)                                       



Mask Generation       Create, edit, apply.

d. Video and multimedia imaging applications require additional services to control the frame rate and direction, set the volume of accompanying sound, highlight or clarify items of interest, and prepare video tapes in standard commercial formats, or digital files from several audio/video sources. These services include:

3.8.2 Exploitation Applications

CIGSS shall include exploitation applications to generate products for external dissemination. In evaluating COTS applications consideration shall be given to the existence of published APIs that allow plug-in modules to be developed for conducting specialized analyses. Examples of the services performed by exploitation applications include:

4. IMPLEMENTATION CONSIDERATIONS (TBD)

This section is reserved for implementation and planning details. Although CIGSS will make extensive use of commercial and government furnished products, some software development will be needed to provide capabilities not available on the commercial market, and to test and integrate commercial software.

4.1 Software Development

4.1.1 Language and Object Oriented Methodology

The objective CIGSS shall be designed and developed using object-oriented technology. The USIS 2000 application program interfaces and CIO prepared IDL specifications for those interfaces shall be used when these become available.

4.1.2 Test and Evaluation

The CIGSS test bed shall be utilized to demonstrate and evaluate candidate components and new technologies for insertion into the CIGSS program, and will provide CIGSS developers with a means to conduct limited operational demonstrations and tests.

4.2 NITFS Certification

Applicable CIGSS software; that is, software which implements the NITFS, shall be certified through testing at the JIEO test facility in accordance with the National Imagery Transmission Format Certification Test and Evaluation Plan (JIEO Circular 9008).

4.3 Security Isolation

CIGSS normally operate in a multi-level secure environment. The following standards and directives provide the necessary guidance for implementing and evaluating trusted computer systems.

DOD 5200.28 Security Requirements for Automated Systems

DOD 5200.28-STD DoD Trusted Computer System Evaluation Criteria (Orange Book)

NCSC-TG-005 Trusted Network Interpretation (Red Book)

NCSC-TG-021 Trusted DBMS Interpretation

Annexes

Annex A

Standard Software Applications

A.1 IESS

The Imagery Exploitation Support System is an integrated set of applications that provides: exploitation requirements management, imagery dissemination management, exploitation task management, and data base management. The application is currently hosted on a DEC Alpha and can be configured in either SCI or collateral standalone systems or as part of a larger supporting/ supported site.

The functions of the IESS are allocated according to:

The Air Force's 497th Intelligence Group (IG)/INDDI is the IESS Program Office. Questions or comments of the IESS development schedule or requirements should be addressed to the Imagery Branch Chief at (202) 767-4647 or DSN 297-4647.

A.2 Image Product Archive

A.2.1 IPA Server Host Application

This section is reserved for a summary of the CIO IDL Specification for the IPA Server Host Application services and interfaces when this becomes available.

A.2.2 IPA Client Application

This section is reserved for a summary of the CIO IDL Specification for the IPA Client Application services and interfaces when this becomes available.

A.3 RULER Mensuration Application

a. Ruler is a software application developed at the National Photographic Interpretation Center (NPIC) to support imagery mensuration. The NPIC maintains and provides configuration management of Ruler software. It performs calculations and produces data on behalf of image analysts and scientists, enabling them to produce intelligence products in support of national policy makers and warfighters. When the Rapid Positioning Capability (RPC) becomes available, Ruler, in conjunction with RPC, will provide the capability to do geopositioning, image adjustment/triangulation, and exploitation.

b. Ruler is an enduring asset of the imagery exploitation community, providing a common, validated, cost effective application. It supports the missions of many exploitation organizations within the community (1) by supporting a diversity of mensuration functions based upon imagery from multiple systems, (2) by running on common hardware and common operating system, and (3) by easily operating with other information systems. Support will extend to those organizations requiring accurate geopositioning and imagery control/triangulation when RPC becomes available.

c. Ruler replaces the Light Table Mensuration System (LTMS) and the Precision Mensuration System (PMS). It can be used as a mensuration engine for integration into a softcopy exploitation system or it can be used with its own interface. It is extensible through its object-oriented design and C++ language implementation. The Application Program Interface for Ruler allows other developers to employ Ruler as a computational element within a softcopy exploitation system; moreover, Ruler has incorporated legacy application software and makes extensive use of COTS software libraries.

Annex B

Graphical Situation Display

The Graphical Situation Display is a Joint program for developing a standard means for graphical reporting. GSD is not a system; it embraces concepts, methodologies, standards, and software modules to be integrated into existing hardware and software architectures.

B.1 GSD Standards

B.2 GSD Applications

Annex C

Support Data Extensions

This annex summarizes the contents of the Support Data Extensions (SDE); the sets of controlled tagged record extensions to the NITF 2.0 file format, needed to process imagery from various sources. The SDE are published and approved as separate documents (see section 2), and may contain additional references to interface specifications and other technical material not identified in this handbook, but which are required for implementing the SDE.

The controlled tagged record extensions are defined in Section 5.9 of the NITF 2.0 standard. Each extension includes the following fields.

- This field contains an alphanumeric identifier that has been registered with the NITF Technical Board (NTB).

- Contains the length in bytes of the data contained in the field (CEDATA) reserved for user-defined data.

- This field contains either binary or character data types defined by and formatted according to a user specification.

Multiple tagged extensions can exist within the tagged record extension area. Each of these areas can contain up to 99,999 bytes of tagged extensions. An overflow mechanism is available to accommodate up to 1GB of tags.

Controlled extensions are submitted to the NTB for approval, and once accepted are subject to configuration management by the NTB.

C.1 Advanced Synthetic Aperture Radar System (ASARS-2) SDE

C.2 Tactical Exploitation Group (TEG) and Advanced Tactical Air Reconnaissance System (ATARS) SDE

The following SDE contain data from various tables found in S20E06

Annex D 


Acronyms and Definitions



A



A3I	Accelerated Architecture Acquisition Initiative (CIO)

AAP	Application Area Profile

AEP	Application Environment Profiles

AITS	Adopted Information Technology Standards

ALS	Airborne Link Segment (CARS)

ANSI	American National Standards Institute

API	Application Program Interface

APS	ASARS Processing Segment (CARS)

ARPA	Advanced Research Projects Agency

ARTAPP Airborne Reconnaissance Technical Architecture Program Plan (DARO) 

ASARS	Advanced Synthetic Aperture Radar System

ATARS	Advanced Tactical Air Reconnaissance System

ATD	Advanced Technology Demonstration

ATM	Asynchronous Transfer Mode

ATR	Automatic Target Recognition



B



BER	Bit Error Rate

BNC	A type of bayonet electrical connector

BUD	Back-Up Dissemination

Byte	Eight bits; historically, one word of data



C



C130	A type of transport aircraft

CARS	Contingency Airborne Reconnaissance System

CATIS	Computer Aided Tactical Information System

CCITT	International Telephone and Telegraph Consultation Committee

CDL	Common Data Link

CHBDL	Common High Bandwidth Data Link

CIGSS	Common Imagery Ground / Surface System

CINC	Commander in Chief

CINF	Community Imagery Needs Forecast (CIO)

CIO	Central Imagery Office

CIP	Common Imagery Processor

CIRC	Circular

COE	Common Operating Environment

CORBA	Common Object Request Broker Architecture

COS	Communications Segment (CARS)

COTS	Commercial off-the-shelf

CSARP	Common SAR Processor

CSMA/CD Carrier Select Multiple Access/Carrier Detect



D



DARO	Defense Airborne Reconnaissance Office

DARP	Defense Acquisitions Reconnaissance Program

DBMS	Database Management System

DCRSI	Digital Cassette Recording System Improved

DCT	Discrete Cosine Transform

DDS	Defense Dissemination System

DIA	Defense Intelligence Agency

DISN	Defense Information System Network

DIWSA	Digital Imagery Workstation Suite Afloat	(JSIPS-N)

DoDIIS	Department of Defense Intelligence Information System

DPCM	Differential Pulse Coded Modulation

DTED	Digital Terrain Elevation Data



E



EEI	1.  Essential Elements of Information		

2.  External Entity Interfaces

EO	Electro-optical

EOS	Earth Observing System

ETRAC	Enhanced TRAC (Tactical Radar Correlator)

ETP	Extended Tether Program

ETUT	Enhanced Tactical Users Terminal



F



FDDI	Fiber-Distributed Data Interface

FEC	Forward Error Correction

FEC-I	Forward Error Correction (effectivity 1)

FEC-II	Forward Error Correction (effectivity 2)

FFT	Fast Fourier Transform

FSD	Fixed Shroud Duplex

FTP	File Transfer Protocol



G



GB	Gigabyte, 1,000 Megabytes (10 to 9th power)

Gbps	Gigabit per second

GCCS	Global Command and Control System

GFI	Government Furnished Information

GIS	Geographical Information System

GOTS	Government off-the-shelf

GPS	Global Positioning System

GSD	1.  Ground Sample Distance		

2.  Graphics Situation Display 

GUI	Graphical User Interface



H



HAE	High Altitude Endurance (UAV)

HdbK	Handbook

HDBS	Host Data Base System

HDLC	High-level Data-link Control

HDTV	High Definition Television

Hi8	Hi-band 8mm magnetic tape format

HiPPI	High Performance Parallel Interface

HiPPI-FP	HiPPI Framing Protocol

HiPPI-PH	HiPPI Physical Layer

HMMWV	High Mobility Multi-purpose Wheeled Vehicle

HRU`	Hardcopy Reconstruction Unit



I



ICD	Interface Control Document

ICMP	Internet Control Message Protocol

IDL	Interoperable Data Link

IDPS	Integrated Deployable Processing System

IEEE	Institute of Electrical and Electronic	

Engineers

IES	Imagery Exploitation Segment (CARS)

IESS	Imagery Exploitation Support System

IFT	Inverse Fourier Transform

IIN	Imagery Information Need

IIRS	Imagery Interpretability Rating Scale

IMINT	Imagery Intelligence

IP	Internet Protocol

IPA	Image Product Archive

IR	Infrared

IRIG	InterRange Instrumentation Group

ISO	International Standard Organization

IWSDB	Integrated Weapon System Database



J



JAC	Joint Analysis Center (Molesworth, UK)

JCMT	Joint Collection Management Tool

JCS	Joint Chiefs of Staff

JDISS	Joint Deployable Intelligence Support System

JIC	Joint Intelligence Center

JIEO	Joint Interoperability and Engineering Office (DISA)

JPEG	Joint Photographic Experts Group

JSIPS	Joint Service Imagery Processing System

JSIPS-N	JSIPS Navy

JTF	Joint Task Force

JWICS	Joint Worldwide Intelligence Communications System



K



K	Kilo (1000)

KB	kilobyte

Kbps	kilobit per second

KCOIC	Korean Combat Operations Intelligence Center



L



LAN	Local Area Network

LCM	Low Cost Media

LO HAE	Low Observable High Altitude Endurance (UAV)



M



MAC	Medium-access control

MAE	Medium Altitude Endurance (UAV)

METT-T	Mission, Enemy, Troops, Terrain, and Time

MFLOPs	Million Floating Point Operations per Second

MIES	Modernized Imagery Exploitation System

MIL-HDBK Military Handbook

MIL-STD	Military Standard

MIPE	Mobile Intelligence Processing Element

MIPS	Millions of Instructions per Second

MIS	1.  Management Information System		

2.  Mission Intelligence Segment (CARS) 

MITRE	Massachusetts Institute of Technology (MIT) Research

MPEG	Motion Picture Experts Group

MSI	Multi-Spectral Imagery



N



NETBLT	Network Block Transfer (protocol)

NDS	National Dissemination System

NIC	National Intelligence Community

NIIRS	National Imagery Interpretation Rating Scale

NIS	National Input Segment

NIST	1. National Intelligence Support Team		

2. National Institute of Standards and Technology

NITF	National Imagery Transmission Format

NITFS	NITF Standard

NMJIC	National Military Joint Intelligence Center

NPIC	National Photographic Interpretation Center

N-TIS	Navy Tactical Input Segment



O



OC-n	Optical Channel n (e.g., OC-3, OC-48)

OO	Object Oriented

OOA	Object Oriented Analysis

OODBMS	Object Oriented DBMS

OOT	Object Oriented Technology

ORD	Operational Requirements Document

OSD	Office of the Secretary of Defense

OSI	Open Systems Interconnection



P



PDU	Protocol Data Units

PINES	Pacific Air Forces Interim National

Exploitation System

P3I	Preprogrammed Product Improvement

PMD	Physical Medium Dependent

POSIX	Portable Operating System Interface



R



R-sets	Reduced resolution sets

RAID	Redundant Arrays of Inexpensive Disks

RAM	Random Access Memory

RDBMS	Relational DBMS

RFC	(Internet) Request for Comment

RFP	Request for Proposal

RG-58U A standardized type and impedance code designation for coaxial cable

RISC	Reduced Instruction Set Computers

RJ-48	A standardized type and size designation for a telephone wire connector

RMS	Requirements Management System

ROM	Read Only Memory

RPC	Rapid Positioning Capability

RTP	Remote Tape Processor

RULER	A software application for doing mensuration an related analysis functions



S



SAR	Synthetic Aperture Radar

SATCOM	Satellite Communications

SBS	Senior Blade Segment (CARS)

SCI	Sensitive Compartmented Information

SCSI-2	Small Computer System Interface (version 2)

SDE	Support Data Extension (to NITF 2.0)

SDH	Synchronous Digital Hierarchy

SIDS	Secondary Imagery Dissemination System

SINCGARS Single Channel Ground and Airborne Radio System

SIPRNET Secret Internet Protocol Router Network

SLIP/PPP Serial Line Internet Protocol/Point to Point Protocol

SONET	Synchronous Optical Network

SP	Standardized Profiles

SPIA	(USIS) Standards Profile for Imagery Archives

SQL	Structured Query Language

ST	A type of optical connector

STANAG	Standardization Agreement (NATO)

S-VHS	Super VHS

SYERS	Senior Year Electro-optical Reconnaissance	

System



T



TACO-2	Tactical Communications (protocol) version 2

TADIL	Tactical Data Information Link

TADIXS	Tactical Data Information Exchange Service

TAFIM	(DoD) Technical Architecture Framework for Information Management

TAP	Technical Architecture Plan (see ARTAPP)

TBD	To be determined

TBR	To be resolved

TCP	Transmission Control Protocol

TEC	Topographic Engineering Center (USA)

TEG	Tactical Exploitation Group

TERABYTE 1,000 Gigabytes (10 raised to the 12TH power)

TFRD	Tape Format Requirements Document

TIBS	Tactical Information Broadcast System (USAF)

TRAC	1.  Tactical Radar Correlator (U2) (USA)		

2.  USA TRADOC Analysis Center (FT Leavenworth, KS)



U



UAV	Unmanned Aerial Vehicle

U-AMPUSIS Architecture Migration Plan(CIO)

UHDDR	Ultra High Digital Data Recorder

UPE	User Portability Extension

USIS	United States Imagery System



V



VHS	Video Helical Scan

VQ	Vector Quantization

W

WAN	Wide Area Network