Section 3
USIGS TECHNICAL ARCHITECTURE

3.1 Description

The Technical Architecture provides the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements (C4ISR Architecture Framework 2.0). The objective of the Technical Architecture is to promote efficiency and interoperability, and to ensure that developers can adequately plan for the introduction of evolving technology. To meet this objective, the Technical Architecture:

This process is continuous and constantly evolving - based on changing Operational and System Architecture foundations and emerging technology.

 

The Technical Architecture captures, refines, and establishes the common building blocks applicable to the overall architecture. This technical guidance can be tailored/profiled by user organizations to facilitate implementation of a structured, disciplined process of system development and evolution. This approach results in agreed-upon standards with a high degree of interoperability and a smoother systems development process. As emerging technology matures and standards become outdated, the Technical Architecture must evolve to establish new standards at reasonable, planned intervals-supporting both stability and progress.

The results of this effort are expressed in the USIGS Technical Architecture (UTA) as an evolving collection of fundamental application-level and infrastructure services, fundamental transaction and system component interfaces, applicable technical standards, and various inter-relationships among these constraints.

3.2 Major Influences

The USIGS Technical Architecture is influenced by and incorporates:

3.3 USIGS Technical Architecture Products

The heart of the USIGS Technical Architecture (UTA) is the enumeration of the technologies that promote efficiency and interoperability. The UTA contains the following Technical Architecture products:

 

- Technical Reference Model(s)

- Mandated Standards Profile of the DoD Joint Technical Architecture

- Conventions and Guidelines

 

 - Emerging Technical Reference Model(s)

- Emerging Standards

- Emerging Technologies

 
 3.3.1 USIGS Technical Architecture Profile (UTAP)

A Technical Reference Model (TRM) is a conceptual representation of the services and interfaces common to an Information System. A TRM provides a mechanism for identifying the key issues associated with applications portability, scalability, and interoperability.

A standards profile is a set or collection of one or more standards to be used collectively to standardize a specific interface, system, or enterprise across a community of systems or within an application area. A profile may contain individual standards that are further defined by a separate, authoritative document called a 'profile' or 'profile of a standard.'

A convention is defined as a non-standardized, but binding specification of practices typically used to maximize interoperability. In contrast to a convention, a guideline is a non-binding specification of accepted methods for non-standardized functionality. Guidelines are not requirements for implementation, but rather constitute 'good practice' among members of the USIGS community.

 
   
Profile of a Standard
Base Standard
  
 
Service
 
JTA Section
 
Name(s)
Document Identifier(s)
 
Name(s)
Document Identifier(s)
 
Remarks
(Imagery Data) [Still Imagery] 2.2.2.2.1.4.4     National Imagery Transmission Format (NITF 2.0) MIL-STD-2500A w/notice #1, 7 Feb 1997 NITF is a part of the more inclusive National Imagery Transmission Format Standard (NITFS) 

 
  2.2.2.2.1.4.4 Computer Graphics Metafile (CGM) Implementation Standard for the NITFS MIL-STD-2301 w/ notice #1 12 Oct 1994 Computer Graphics Metafile ANSI/ISO 8632 

 

 MIL-STD-2301 is a 'profile' of ANSI/ISO 8632
  2.2.2.2.1.4.4 JPEG as profiled for NITFS MIL-STD-188-198A w/ notice #1 12 Oct 94 JPEG ANSI/ISO 10918-1 Note: not interoperable with JFIF
 
Figure 3-1 Mandated Profile of the DoD Joint Technical Architecture Excerpt (sample)
Table 3-1 USIGS Technical Architecture Profile
 
Name: USIGS Technical Architecture Profile
Description and Purpose of Product:  

The USIGS Technical Architecture Profile (UTAP) consists of: 

    • Technical Reference Model(s)
    • Mandated Profile of the DoD Joint Technical Architecture
    • Conventions and Guidelines
The USIGS Technical Architecture Profile (UTAP) includes an extension of the DoD Technical Reference Model (TRM). A TRM provides a high-level graphical representation of an information system domain showing major service areas and a more detailed textual description of services and interfaces. The USIGS will leverage existing, established reference models and extend them as necessary to support an imagery and geospatial perspective. The DoD TRM is extended for the USIGS to accommodate the Object Management Group's (OMG's) Object Management Architecture (OMA) and support for the DII COE. This extended model defines a set of services and interfaces common to the USIGS, and provides the construct to identify where standards are needed and where competing standards exist. The intent is to place the USIGS on a transition path toward a target environment characterized by distributed object computing and open, interoperable systems. 

The USIGS Technical Architecture Profile (UTAP) includes a profile of the DoD Joint Technical Architecture (JTA) for use by the IGC. Thus, it is the approved list of standards for implementation within the USIGS. The UTAP is organized by reference model service categories and contains the minimum set of mandatory standards for each service area with which a system must comply if implementing that particular service. The Standards Profile cites the standards reference, a brief description and status of each standard and any supporting profile. A standards profile is a set or collection of one or more standards to be used collectively to standardize a specific interface, system, or enterprise across a community of systems or within an application area. A standards profile may contain individual standards that may be further defined by separate, authoritative documents, each of which is referred to as a 'profile' or a 'profile of a standard.' Each such profile further refines the implementation of the original standard to ensure interoperability. 

Conventions are process or procedure specifications, not formally approved by an accepted standards organization, that describe organizational practices essential to information technology implementation. In the USIGS, conventions are agreed to within the IGC and have the same effect as standards in order to maximize interoperability.  

Guidelines are recommended, but not required, practices. Whenever possible, USIGS guidelines will be aligned with those from other communities with which the USIGS must interoperate.
Audience: USIGS senior and mid-level managers, program executive officers, program managers, system architects, system developers, system operators
Creator/Maintainer: NIMA ST/ARU
Format: Multiple pages of text, figures, and tables
Applicable Tools: TBD
Dependent On: National Imagery and Mapping Agency (DoDD 5105.60); NIMA Business Plan; NIMA Work Plan; USIGS Activity Hierarchy; USIGS Activity Diagram; USIGS Information Exchange Requirements Matrix; USIGS systems descriptions; DoD Joint Technical Architecture; Object Management Group (OMG) Object Management Architecture (OMA), DII COE Specs.
Processes Influenced: Planning Process - Mandatory 

Requirements Process - Mandatory 

Resource Management - Guidance 

Acquisition Process - Mandatory

 Community Interaction - Dependent
Revision Cycle: Annually, or as required due to organization or mission changes
Controlling Authority: NCCB
Classification: UNCLASSIFIED
 

3.3.2 USIGS Standards Technology Forecast

Realizing that technology and associated standards evolve over time, this part of the UTA seeks to identify and discuss a variety of emerging reference models, standards, and technologies that are expected to have a significant effect in the Imagery and Geospatial Community (IGC). Emerging standards are those that are expected to augment or replace currently-mandated standards. Also discussed are those functional/interface areas where it is felt that standards are needed and where NIMA and the IGC must be proactive to facilitate technology and standards development.
 

 
4.2.3 The USIGS ISP of Basic Image Interchange Format (BIIF) 

NITF 2.0 will be superseded by NITF 2.1, MIL-STD 2500B (approved 22 August 1997 by the ISMC), and by the USIGS ISP of BIIF (ISO/IEC 12087-5 DIS) in the 1999 timeframe. NITF is the core of the NITF Suite of standards, and is coupled with additional standards for compression, graphics, and communications. It is mandated for all C4I systems disseminating secondary imagery, and is required for interoperability within the USIGS. The ISP and NITF 2.1 are technically equivalent and will not require software upgrades to maintain interoperability.
 
Figure 3-2 USIGS Emerging Standards Excerpt (sample)
 
 
The CORBA environment includes both CORBA services [CORBA97c] and CORBA facilities [CORBA97b] at the time of this writing (the components of each category are discussed in this document in Sections 2.2.4 and 2.2.3, respectively). There have been 14 CORBA services specified (Table 5-2) and one other (Collection Service) identified but not defined, but at the time of this writing, only a few were available as products from CORBA vendors and several were being reconsidered by OMG. Specifically, the Naming, Event, Transaction, Trader, and Security services were available as products from most, if not all, of the ORB vendors and the Persistence Service specification was in the process of being replaced by a more implementable specification with resulting products becoming available in the 1998-1999 timeframe. Others, such as the Security and Relationship Service specifications, are expected to be enhanced in the 1997-1998 timeframe with resulting products becoming available in the 1998-1999 timeframe. The longer term future should see refinement of the various service specifications, but there are no additional services envisioned as of the time of this writing. 
 
 
Figure 3-3 USIGS Emerging Technologies Excerpt (sample)
 
Table 3-2 USIGS Standards Technology Forecast
 
  

Name: USIGS Standards Technology Forecast
  

Description and Purpose of Product: The Standards Technology Forecast consists of three parts: Emerging Technical Reference Model(s), Emerging Standards, and Emerging Technologies. The Emerging Technical Reference Model(s) discussion focuses on additional reference models of interest to the IGC. The Emerging Standards discussion focuses on specifications that may be included in the UTAP in the future. Such specifications may reflect either new standards or replacement for standards currently mandated in the UTAP. The Emerging Technologies discussion identifies the influences of future technologies that are likely to contribute to changes in the businesses processes and functional activities reflected in the USIGS Operational Architecture. This section also explores how existing USIGS standards will need to evolve, or be created, in order to enable appropriate implementations of these new technologies. 

 
Audience: USIGS senior and mid-level managers, program executive officers, program managers, system architects, system developers, system operators 

 
Creator/Maintainer: NIMA ST/ARU 

 
Format: Multiple pages of text, figures, and tables 

 
Applicable Tools: TBD 

 
Dependent On: National Imagery and Mapping Agency (DoDD 5105.60); NIMA Business Plan; NIMA Work Plan; USIGS Activity Hierarchy; USIGS Activity Diagrams; USIGS Information Exchange Requirements Matrix; USIGS System Architecture; Information Technology Standards Guidance 3.1; DoD Joint Technical Architecture 1.0, DII COE Specifications. 

 
Processes Influenced: Planning Process - Guidance Requirements Process - Guidance  Resource Management - Guidance 

Acquisition Process - Guidance

 Community Interaction - Dependent 

 
Revision Cycle: Annually, or as required due to organization or mission changes. 

 
Controlling Authority: NCCB
Classification: UNCLASSIFIED
 

 

3.4 USIGS Technical Architecture Relationships to Other USIGS Architecture

Based on requirements derived from the USIGS Operational Architecture Description, the USIGS Technical Architecture provides the basis for a synergistic relationship among all elements of the USIGS Architecture. Figure 3-4 graphically depicts these relationships.

 

 
Figure 3-4 USIGS Technical Architecture Relationships
 

A: The UOAD identifies activities for which services must be provided. The USIGS Technical Architecture identifies the standards specifications that are necessary to satisfy those requirements.

B: The Technical Architecture mandates the use of the USIGS Conceptual Data Model, which standardizes data element usage in the USIGS. The USIGS Object Model included in the UTA provides the logical linkage between USIGS services and the UCDM. The Technical Architecture also identifies data standards that must be used in the UCDM e.g., Feature Attribute Coding Catalog (FACC).

C: The Technical Architecture identifies the Mission Specific Application categories, the applicable common support services, and applicable APIs for the SIEM. These items are mapped to the Operations Activities identified in the USIGS Operational Architecture.

D: The Technical Architecture identifies: 1) applicable formal standards specifications, 2) local-standards specifications, and 3) legacy standards that may be used by Interface Control Documents (ICDs) or other forms of specification.

 

Table of Contents ; Preface ; 1. Overview and Summary Information ; 2. USIGS Operational Architecture ; 3. USIGS Technical Architecture ; 4. USIGS System Architecture ; 5. USIGS Conceptual Data Model ; 6. USIGS Migration Plan ; 7. USIGS Architecture Compliance ; Appendix 1. Acronym List ; Appendix 2. C4ISR Architecture Framework Compliance ; Appendix 3. USIGS Glossary Extract ; Appendix 4. USIGS Architecture Compliance Checklist
Point of Contact: Mark Owens
Last updated by Mark Owens on 9 June 1999.