Distribution Statement A: Approved for public release; distribution unlimited.
Executive Summary
Effective military operations must respond with a mix of forces, anywhere in the world, at a moment's notice. The ability for the information technology systems supporting these operations to interoperate--work together and exchange information--is critical to their success. The lessons learned from conflicts like Desert Shield/Desert Storm resulted in a new vision for the Department of Defense (DoD). Joint Vision 2010 (JV 2010) is the conceptual template for how America's Armed Forces will channel the vitality and innovation of their people, and leverage technological opportunities to achieve new levels of effectiveness in joint warfighting. The DoD Joint Technical Architecture (JTA) is crucial to achieving JV 2010.
The JTA provides DoD systems with the basis for the needed seamless interoperability. The JTA defines the service areas, interfaces, and standards (JTA elements) applicable to all DoD systems, and its adoption is mandated for the management, development, and acquisition of new or improved systems throughout DoD. The JTA is structured into service areas based on the DoD Technical Reference Model (TRM). The DoD TRM originated from the Technical Architecture Framework for Information Management (TAFIM) and was developed to show which interfaces and content needed to be identified. These are depicted as major service areas in the DoD TRM.
Standards and guidelines in the JTA are stable, technically mature, and publicly available. Standards and guidelines that do not yet meet these criteria, but are expected to mature to meet them in the near-term (within three years), are cited as "emerging standards" in the expectation that they will be mandated in future versions of the JTA.
The JTA consists of two main parts: the JTA Core, and the JTA domains. The JTA Core contains the minimum set of JTA elements applicable to all DoD systems to support interoperability. The JTA annexes contain additional JTA elements applicable to specific functional domains (families of systems). These elements are needed to ensure interoperability of systems within each domain but may be inappropriate for systems in other domains. The current version of the JTA includes domains for Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR); Combat Support; Modeling and Simulation; and Weapon Systems. Where subsets of an application domain (subdomain) have special interoperability requirements, the JTA includes subdomains containing JTA elements applicable to systems within that subdomain. The intention is that a system within a specific subdomain adopt the JTA elements contained in the relevant subdomain, the JTA elements contained in the parent domain, and the JTA elements contained in the JTA Core.
The JTA is complementary to, and consistent with, other DoD programs and initiatives aimed at the development and acquisition of effective, interoperable information systems. These include DoD's Specification and Standards Reform; Implementation of the Information Technology Management Reform Act (ITMRA); Defense Modeling and Simulation Initiative; Evolution of the DoD TRM; Defense Information Infrastructure Common Operating Environment (DII COE); and Open Systems Initiative.
Development of the JTA is a collaborative effort, conducted by the JTA Development Group (JTADG), directed by the Technical Architecture Steering Group (TASG), and approved by the Architecture Coordination Council (ACC). Members represent the DoD Components (Office of the Secretary of Defense [OSD], the Military Departments, the Office of the Joint Chiefs of Staff [OJCS], the Unified and Specified Combatant Commands, and the Defense Agencies) and components of the Intelligence Community.
The JTA is a living document and will continue to evolve with the technologies, marketplace, and associated standards upon which it is based.
Overview of the Department of Defense Joint Technical Architecture
Introduction
Warfighter battlespace is complex and dynamic, requiring timely and informed decisions by all levels of military command. There is an unprecedented increase in the amount of data and information necessary to conduct operational planning and combat decision-making. Information concerning targets, movement of forces, condition of equipment, levels of supplies, and disposition of assets--both friendly and unfriendly--must be provided to joint commanders and their forces. Therefore, information must flow quickly and seamlessly among all tactical, strategic, and supporting elements.
As shown in See : DoD Warfighter Information Technology Environment, warfighters must be able to work together within and across Services in ways not totally defined in today's operational concepts and/or architectures. They must be able to obtain and use intelligence from national and theater assets that may be widely dispersed geographically. Today's split-base/reach-back concept requires them to obtain their logistics and administrative support from both home bases and deployed locations. All of this requires that information flow quickly and seamlessly among DoD's sensors, processing and command centers, shooters, and support activities to achieve dominant battlefield awareness and move inside the enemy's decision loop.
|
|
The DoD Joint Technical Architecture (hereinafter referred to as the JTA) provides the minimum set of standards that, when implemented, facilitates this flow of information in support of the warfighter. The JTA standards promote:
The current JTA concept is focused on the interoperability and standardization of information technology (IT).
Purpose
See Overview of the Department of Defense Joint Technical Architecture provides an overview of the JTA. It includes the JTA purpose, scope, background, and applicability; introduces basic architecture concepts; and discusses the selection criteria for standards incorporated in the document.
Also addressed are the roles of the DoD Technical Reference Model and the Combined Communications-Electronics Board (CCEB).
The JTA improves and facilitates the ability of our systems to support joint and combined operations in an overall investment strategy.
Provides the foundation for interoperability among all tactical, strategic, and combat support systems.
Mandates IT standards and guidelines for DoD system development and acquisition that will facilitate interoperability in joint and coalition force operations. These standards are to be applied in concert with DoD standards reform.
Scope (Applicability)
The JTA is considered a living document and will be updated periodically as a collaborative effort among the DoD Components (Commands, Services, and Agencies) to leverage technology advancements, standards maturity, open systems, commercial product availability, and changing requirements.
The JTA is critical to achieving the envisioned objective of a cost-effective, seamlessly integrated environment. Achieving and maintaining this vision requires interoperability:
This version of the JTA mandates the minimum set of standards and guidelines for the acquisition of all DoD systems that produce, use, or exchange information. The applicable mandated standards in the JTA are the starting set of standards for a system, and additional standards may be used to meet requirements if they are not in conflict with standards mandated in the JTA. The JTA is used by anyone involved in the management, development, or acquisition of new or improved systems within DoD. Specific guidance for implementing this JTA is provided in the separate DoD Component JTA implementation plans. Operational requirements developers are cognizant of the JTA in developing requirements and functional descriptions. System developers use the JTA to facilitate the achievements of interoperability for new and upgraded systems (and the interfaces to such systems). System integrators use it to foster the integration of existing and new systems.
The JTA is updated periodically with continued DoD Component participation.
Background
The evolution of a national military strategy in the post-Cold War era and the lessons learned from conflicts like Desert Shield/Desert Storm have resulted in a new vision for DoD. Joint Vision 2010 is the conceptual template for how America's Armed Forces will channel the vitality and innovation of their people and leverage technological opportunities to achieve new levels of effectiveness in joint warfighting. This template provides a common direction to our Services in developing their unique capabilities within a joint framework of doctrine and programs as they prepare to meet an uncertain and challenging future. The Chairman of the Joint Chiefs of Staff said in Joint Vision 2010, "The nature of modern warfare demands that we fight as a joint team. This was important yesterday, it is essential today, and it will be even more imperative tomorrow."
Joint Vision 2010 (JV 2010) creates a broad framework for understanding joint warfare in the future, and for shaping Service programs and capabilities to fill our role within that framework. JV 2010 defines four operational concepts: Precision Engagement, Dominant Maneuver, Focused Logistics, and Full Dimensional Protection. These concepts combine to ensure that American forces can secure Full Spectrum Dominance, i.e., the capability to dominate an opponent across the range of military operations and domains. Furthermore, Full Spectrum Dominance requires Information Superiority, i.e., the capability to collect, process, analyze, and disseminate information while denying an adversary the ability to do the same. Interoperability is crucial to Information Superiority.
Recognizing the need for joint operations in combat and the reality of a shrinking budget, the Assistant Secretary of Defense (Command, Control, Communications, and Intelligence) (ASD[C3I]) issued a memorandum on 14 November 1995 to Command, Service, and Agency principals involved in the development of Command, Control, Communications, Computers, and Intelligence (C4I) systems. This directive tasked them to "reach a consensus of a working set of standards" and "establish a single, unifying DoD technical architecture that will become binding on all future DoD C4I acquisitions" so that "new systems can be born joint and interoperable, and existing systems will have a baseline to move toward interoperability."
A Joint Technical Architecture Working Group (JTAWG), chaired by ASD(C3I), was formed, and its members agreed to use the U.S. Army Technical Architecture (ATA) as the starting point for the JTA. Version 1.0 of the JTA was released on 22 August 1996 and was immediately mandated by the Under Secretary of Defense, Acquisition and Technology (USD[A&T]) and ASD(C3I) for all new and upgraded C4I systems in DoD.
JTA Version 2.0 development began in March 1997 under the direction of a Technical Architecture Steering Group (TASG), co-chaired by ASD(C3I) and USD(AT&L) Open Systems Joint Task Force (OSJTF). The applicability and scope of Version 2.0 of the JTA was expanded to include the information technology in all DoD systems.
JTA Version 3.0 development began in June 1998. JTA Version 3.0 includes additional subdomains and incorporated the newly developed DoD Technical Reference Model (DoD TRM). JTA Version 3.1 mandated a Gigabit Ethernet standard.
JTA Version 4.0 development began in November 1999. JTA Version 4.0 removes the Orange Book mandate and mandates the Common Criteria.
Architectures Defined
The C4ISR Architecture Framework (CAF) provides information addressing the development and presentation of architectures. The framework provides the rules, guidance, and product descriptions for developing and presenting architectures to ensure a common denominator for understanding, comparing, and integrating architectures across and within DoD.
An architecture is defined as the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time. DoD has implemented this by defining an interrelated set of views: operational, system, and technical. See : Architecture Views Relationships shows the relationship among the three views. The definitions are provided here to ensure a common understanding of the three views.1
|
|
Operational Architecture View
The operational architecture (OA) view is a description of the tasks and activities, operational elements, and information flows required to accomplish or support a military operation.
It contains descriptions (often graphical) of the operational elements, assigned tasks and activities, and information flows required to support the warfighter. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges in detail sufficient to ascertain specific interoperability requirements.
Technical Architecture View
The technical architecture (TA) view is 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.
The technical architecture view provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. The technical architecture view includes a collection of the technical standards, conventions, rules, and criteria organized into profile(s) that govern system services, interfaces, and relationships for particular systems-architecture views and that relate to particular operational views.
Systems Architecture View
The systems architecture (SA) view is a description, including graphics, of systems and interconnections providing for, or supporting, warfighting functions. For a domain, the systems architecture view shows how multiple systems link and interoperate, and may describe the internal construction and operations of particular systems within the architecture. For the individual system, the systems architecture view includes the physical connection, location, and identification of key nodes (including materiel-item nodes), circuits, networks, warfighting platforms, etc., and it specifies system and component performance parameters (e.g., mean time between failure, maintainability, availability). The systems architecture view associates physical resources and their performance attributes to the operational view and its requirements following standards defined in the technical architecture.
Relationships between the C4ISR Architecture Framework 2.0 and the DoD JTA
The C4ISR Architecture Framework defines the technical architecture view and a set of standard technical products for DoD use. The JTA is one of the Universal Reference Resources named in the CAF. The JTA is the primary source document to the essential and supporting Technical Architecture products defined in the C4ISR Architecture Framework. Standards chosen from the JTA and other sources to meet system and operational requirements are incorporated into the technical architecture View.
Document Organization
The JTA is organized into a main body, followed by domains, subdomains, and a set of appendices. This section describes the structure of the document.
General Organization
The main body identifies the "Core" set of JTA elements consisting of service areas, interfaces, and standards. Each section of the main body, except for the overview, is divided into four subsections as follows:
Introduction, Purpose, Scope, and Background: These subsections are for information purposes only. They define the purpose and scope of the document and the section and provide background descriptions and definitions that are unique to this section.
Service Area and Services: This subsection describes the technical overview of the Services in this section.
Mandated Standards: This subsection identifies mandatory standards or practices. Each mandated standard or practice is clearly identified on a separate bulletized ( ) line and includes a formal reference citation suitable for inclusion within Requests for Proposals (RFPs), Statements of Work (SOWs), or Statements of Objectives (SOOs).
Emerging Standards: This subsection provides an information-only description of standards that are candidates for possible addition to the JTA mandates. Each emerging standard is clearly identified on a separate dashed ( - ) line. The purpose of listing these candidates is to help the program manager determine those areas likely to change in the near term (within three years) and suggest those areas in which "upgradability" should be a concern. The expectation is that emerging standards will be elevated to mandatory status when implementations of the standards mature. Emerging standards may be implemented, but shall not be used in lieu of a mandated standard.
Information Technology Standards
The JTA Core, or main body, addresses commercial and government standards common to most DoD information technology, grouped into categories each of which addresses a set of functions common to most DoD IT systems. The information technology categories are:
Information Processing Standards: See Information Processing Standards describes Government and commercial information processing standards DoD uses to develop integrated, interoperable systems that meet the warfighters' information processing requirements.
Information Transfer Standards: See Information Transfer Standards describes the information transfer standards and profiles that are essential for information transfer interoperability and seamless communications. This section mandates the use of the open systems standards used for the Internet and the Defense Information System Network (DISN).
Information Modeling, Metadata, and Information Exchange Standards: See Information Modeling, Metadata, and Information Exchange Standards describes the use of integrated information modeling and mandates applicable standards. Information modeling consists of activity, data, and object modeling. This section explains the use of the DoD Command and Control (C2) Core Data Model (C2CDM) and the Defense Data Dictionary System (DDDS), formerly the Defense Data Repository System (DDRS). This section also mandates information standards, including message formats.
Human-Computer Interface Standards : See Human-Computer Interface Standards provides a common framework for Human-Computer Interface (HCI) design and implementation in DoD systems. The objective is the standardization of user interface implementation options, enabling DoD applications to appear and behave in a reasonably consistent manner. The section specifies HCI design guidance, mandates, and standards.
Information Security Standards : See Information Security Standards prescribes the standards and protocols to be used to satisfy security requirements. This section provides the mandated and emerging security standards that apply to JTA sections 2 through 5.
The JTA Core establishes the minimum set of rules governing information technology across all DoD systems. Additional domain-specific mandates are found in the corresponding domains and subdomains. They include standards for information processing, information transfer, the structure of information and data, human-computer interface for information entry and display, and information system security. Information technology includes any equipment or interconnected system or subsystem of equipment used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information.
Domains and Subdomains
The JTA Core contains the common service areas, interfaces, and standards (JTA elements) applicable to all DoD systems to support interoperability. Recognizing that there are additional JTA elements common within families of related systems (i.e., domains), the JTA adopted the domain and subdomain notion. A domain represents a grouping of systems sharing common functional, behavioral, and operational requirements. JTA domains and subdomains are intended to exploit the common service areas, interfaces, and standards supporting interoperability across systems within the domain and/or subdomain.
A JTA domain contains domain-specific JTA elements applicable within the specified family of systems to further support interoperability within the systems represented in the domain--in addition to those included in the JTA Core. A domain may be composed of multiple subdomains. Subdomains represent the decomposition of a domain (referred to as the subdomain's parent domain) into a subset of related systems, exploiting additional commonalities and addressing variances within the domain. A subdomain contains domain-specific JTA elements applicable within the specified family of systems to further support interoperability within the systems represented in the subdomain--in addition to those included in the JTA Core and in the parent domain. The relationships between the JTA Core, domains, and subdomains currently in the JTA are illustrated in See : JTA Hierarchy Model.
|
|
The current domains and subdomains are listed as follows:
A program manager or engineer specifying or applying JTA standards for a specific system will first select all appropriate JTA Core elements, and then those included in the relevant domain and subdomain.
The goal is to build on these annexes by incorporating the requirements of additional domains and subdomains. Each domain and subdomain includes an introduction clearly specifying the purpose, scope, description of the domain, and background of the domain and subdomain. As necessary, each domain and subdomain provides a list of domain-specific standards and guidance in a format
consistent with the JTA Core. Domains and subdomains generally use the DoD Technical Reference Model (DoD TRM) defined in See DoD Technical Reference Model, but may also use a different or expanded model.
Appendices (Appendix A, B, C, D, E, F)
The appendices provide supporting information (e.g., how to get a copy of mandated standards) and available links to standards organizations' web site, which facilitate the use of the document, but are not mainline to its purpose.
See contains an abbreviations and acronyms list.
See now a stand-alone document on the JTA Web site, contains "currently mandated," "previously mandated," and "emerging" standards for each JTA service area.
See is a list of the organizations from which documents cited in the JTA may be obtained.
See is a list of documents (e.g., a memorandum, a publication) that directs the reader's attention to a source of more information on a subject.
See describes the relationship of the JTA to the DoD standards reform begun in June 1994 and addresses the relevance of the reform waiver policy to the JTA.
See is a list of terms with their meanings.
DoD Technical Reference Model
The DoD Technical Reference Model (TRM), Version 1.0, 5 November 1999, and the core set of standards mandated in the JTA define the target technical environment for the acquisition, development, and support of DoD information technology. The purpose of the TRM is to provide a common conceptual framework and a common vocabulary so that the diverse components within DoD can better coordinate acquisition, development, and support of DoD information technology. Interoperability is dependent on the establishment of a common set of services and interfaces that system developers can use to resolve technical architectures and related issues.
The TRM structure is intended to reflect the separation of data from applications, and applications from the computing platform--a key principle in achieving open systems. The JTA has adapted the TRM to serve as the framework for presenting JTA-mandated standards. The JTA's use of the TRM ensures the use of consistent definitions needed to define architectural and design components. The model identifies service areas (i.e., a set of capabilities grouped by functions) and their interfaces. The TRM was chosen as the framework of the JTA because of the model's inherent support of open system concepts. As illustrated in See : DoD Technical Reference Model (DoD TRM), the model is partitioned into the following: an Application Software Entity that includes both Mission Area and Support Applications; an Application Platform Entity that contains the system services (e.g., User Interface and Data Management services) and operating system services; Physical Environment Services; and External Environment; and a number of interfaces. The interfaces provide support for a wide range of applications and configurations and consist of the following: Application Program Interfaces (APIs) and External Environment Interfaces (EEIs).
The following JTA Core services are equivalent to their corresponding TRM system services contained within the Application Platform Entity:
|
|
The relationship between the sections in the JTA and the TRM service areas are as follows:
See Information Processing Standards Information Processing Standards specifies standards for the User Interface (See User Interface Services), Data Management (See Data Management Services), Data Interchange (See Data Interchange Services), Graphics (See Graphic Services), Operating System (See Operating System Services), Internationalization (See Internationalization Services), and Distributed Computing (See Distributed Computing Services) service areas, and the latter's two subordinate paragraphs become See Remote-Procedure Computing and See Distributed-Object Computing respectively. This section also references, but does not specify, any standards for the Software Engineering (See Software Engineering Services), Communications (See Communications Services), Security (See Security Services), and System Management (See System Management Services) service areas.
See : Interface Translation Table provides the interface relationships for See : DoD Technical Reference Model (DoD TRM).
See Information Transfer Standards Information Transfer Standards specifies standards for the Communications (See Communications through See Transmission Media) and Network and System Management (See Network and Systems Management) service areas applicable to both system and network management.
See Information Modeling, Metadata, and Information Exchange Standards Information Modeling, Metadata, and Information Exchange Standards addresses standards for an area that is not currently elaborated, but is supported by engineering support, data management, and software engineering services in the TRM.
See Human-Computer Interface Standards Human Computer Interface Standards complements those cited for User Interface Services in See User Interface Services User Interface Services.
See Information Security Standards Information Security Standards, specifies security standards that are relevant to the service areas discussed in See Information Processing Standards, See Information Transfer Standards, and See Human-Computer Interface Standards.
At this time, the JTA does not include standards for all of the services identified in the TRM.
Key Considerations in Using the JTA
The JTA is used to determine the mandated standards within applicable service areas for implementation within new or upgraded systems. However, there are several key considerations in using the JTA.
The mandatory standards in the JTA must be implemented or used by systems that have a need for the corresponding service areas. A standard is mandatory in the sense that if a service/interface is going to be implemented, it shall be implemented in accordance with the associated standard. If a required service can be obtained by implementing more than one standard (e.g., operating system standards), the appropriate standard should be selected based on system requirements.
The JTA is a forward-looking document. It guides the acquisition and development of new and emerging functionality and provides a baseline toward which existing systems will move. It is a compendium of standards (for interfaces/services) that should be used now and in the future. It is not a catalog of all information technology standards used within today's DoD systems. If legacy standards are needed to interface with existing systems, they can be implemented on a case-by-case basis in addition to the mandated standard.
Element Normalization Rules
As the JTA evolves, the JTA elements contained in the JTA Core, domains, and subdomains need to be periodically revisited and updated to ensure correctness. The JTA normalization rules in this section address the movement of elements from subdomain to domain, and from domains into the Core.
All standards are placed in the Core unless they are justified as unacceptable to meet domain-specific requirements. When Core standards cannot meet the requirements of a specific domain,
JTA elements are removed from the JTA Core and placed in the appropriate domain. Likewise, when domain standards cannot meet subdomain-specific requirements, those will be removed from the domain and placed in the appropriate subdomain.
The intent of the above normalization rules is as follows: (1) The Core applies to all DoD systems; (2) the JTA Core contains selected standards for as many JTA services as possible; and (3) the JTA provides the minimum number of standards for a specified service or interface.
JTA Relationship to DoD Standards Reform
The DoD standards reform was begun in June 1994 when the Secretary of Defense issued a memorandum entitled "Specifications and Standards - A New Way of Doing Business." This memorandum directs that performance-based specifications and standards or nationally recognized private-sector standards be used in future acquisitions. The intent of this initiative is to eliminate non-value-added requirements, and thus reduce the cost of weapon systems and materiel, remove impediments to getting commercial state-of-the-art technology into weapon systems, and integrate the commercial and military industrial bases to the greatest extent possible.
The JTA implements standards reform by selecting the minimum standards necessary to achieve joint interoperability. The JTA mandates commercial standards and practices to the maximum extent possible. Use of JTA-mandated standards or specifications in acquisition solicitations will not require a waiver from standards reform policies. All mandatory standards in the JTA are of the types that have been identified by the DoD standards reform as waiver-free or for which an exemption has already been obtained. Additional information on this topic can be found in See .
Standards Selection Criteria
The standards selection criteria used throughout the JTA focus on mandating only those items critical to interoperability that are based primarily on commercial open system technology, are implementable, and have strong support in the commercial marketplace. Standards will only be mandated if they meet all of the following criteria:
The following preferences were used to select standards:
Standards that are commercially supported in the marketplace with validated implementations available in multiple vendors' mainstream commercial products took precedence.
International or national industry standards were preferred over military or other government standards.
Standards that can be implemented without requiring intellectual property (patent) rights were generally preferred.
Many standards have optional parts or parameters that can affect interoperability. In some cases, an individual standard may be further defined by a separate, authoritative document called a "profile" or a "profile of a standard," which further refines the implementation of the original standard to ensure proper operation and assist interoperability.
The word "standards" as referred to in the JTA is a generic term for the collection of documents cited herein. An individual "standard" is a document that establishes uniform engineering and technical requirements for processes, procedures, practices, and methods. A standard may also establish requirements for selection, application, and design criteria of material. The standards cited in the JTA may include commercial, federal, and military standards and specifications, and various other kinds of authoritative documents and publications.
Configuration Management
The JTA is configuration-managed by the Joint Technical Architecture Development Group (JTADG), under the direction of the DoD Technical Architecture Steering Group (TASG) and approved by the Architecture Coordination Council (ACC). These groups consist of members representing DoD and components of the Intelligence Community. See : JTA Development Group (JTADG) Voting Membership shows the organizations that have voting memberships in the JTADG and TASG.
The JTA Management Plan describes the process by which the JTA will be configuration-managed. This document, as well as the charter for the JTADG, may be found on the Defense Information Systems Agency (DISA) Center for Standards (CFS) JTA Web site: http://www-jta.itsi.disa.mil .
Suggested changes to, or comments on, the JTA originating from DoD Components (Office of the Secretary of Defense [OSD], the Military Departments, the Office of the Joint Chiefs of Staff [OJCS], the Unified and Specified Combatant Commands, and the Defense Agencies) should be submitted via the appropriate official JTA Component Representative listed on the JTA Web site. These representatives will integrate and coordinate received comments for submission as official DoD Component-sponsored comments.
Where a standard is highlighted and underscored , it is hyperlinked to the DoD Joint Technical Architecture (JTA) List of Mandated and Emerging Standards (formerly Appendix B). A "link" symbol ( ) at the end of a citation for a standard indicates the hyperlink to the web site where the standard can be obtained. Clicking on the "link" symbol will access the corresponding web site.
Industry and other non-DoD suggested changes should be submitted through DISA CFS via electronic mail to: jta@www.disa.mil .
Information Processing Standards
Introduction
Purpose
The purpose of this section is to specify the Joint Technical Architecture (JTA) Government and commercial information processing standards DoD will use to develop integrated interoperable systems that directly or indirectly support the warfighter.
Scope
This section applies to mission-area, See : HCI Development Guidance support application, See : JTA Hierarchy Model and application platform service software. This section does not cover communications standards needed to transfer information between systems (defined in See Information Transfer Standards), nor standards relating to information modeling (process, data, and simulation), data elements, or military-unique message set formats (defined in See Information Modeling, Metadata, and Information Exchange Standards).
Background
Information processing standards provide the data formats and instruction-processing specifications required to represent and manipulate data to meet information technology (IT) mission needs. The standards in this section are drawn from widely accepted commercial standards that meet DoD requirements. Where necessary for interoperability, profiles of commercial standards are used. Military standards are mandated only when suitable commercial standards are not available.
Mandated Standards
The following sections provide the applicable mandated standards that shall be used for the selection of commercial off-the-shelf (COTS) or Government off-the-shelf (GOTS) software or in the development of Government software. Appendix B links to the table DoD Joint Technical Architecture List of Mandated and Emerging Standards on the JTA web site.
Application Software Entity
The Application Software Entity is one part of the DoD Technical Reference Model (TRM) that includes both mission-area applications and support applications. Mission-area applications implement specific users' requirements and needs (e.g., personnel, material, management). This application software may be COTS, GOTS, custom-developed software, or a combination of these.
Common support applications (e.g., e-mail and word processing) are those that can be standardized across individual or multiple mission areas. The services they provide can be used to develop mission-area-specific applications or can be made available to the user. The TRM defines six support application categories: Multimedia, Communications, Business Processing, Environment Management, Database Utilities, and Engineering Support. The definitions of these categories are found in the DoD Technical Reference Model, Version 1.0, 5 November 1999.
Application Platform Entity
The Application Platform Entity is the second layer of the DoD TRM, as shown in See : DoD Technical Reference Model (DoD TRM), and includes the common system services upon which required information processing functionality is built. The Application Platform Entity is composed of 11 service areas. The corresponding mandates are provided in the following subsections.
Service Areas
Eleven primary system services and operating systems services are defined within the Application Platform Entity: Software Engineering, User Interfaces, Data Management, Data Interchange, Graphics, Communications, Operating System, Internationalization, Security, System Management, and Distributed Computing Services.
Software Engineering Services
The software engineering services provide system developers with the tools that are appropriate to the development and maintenance of applications. There are no mandated standards for this service area.
Language services provide the basic syntax and semantic definition for use by developers to describe the desired software function. "Programming language selections should be made in the context of the system and software engineering factors that influence overall life-cycle costs, risks, and potential for interoperability."2 Computer languages should be used in such a way as to minimize changes when compilers, operating systems, or hardware change. To maximize portability, the software should be structured where possible so it can be easily ported.
User Interface Services
User Interface Services control how a user interfaces with an information technology system. The Common Desktop Environment (CDE) provides a common set of desktop applications and management capabilities for environments similar to the Microsoft Windows desktop environment. CDE supports The Open Group Motif-based application execution. Both CDE and Motif applications use the underlying X-Windows system. The Win32 Application Program Interface (API) set provides similar services for Microsoft Windows applications. Refer to See Human-Computer Interface Standards for Human-Computer Interface (HCI) style guidance and standards.
User Interface Service -- POSIX
The Common Desktop Environment (CDE) provides a common set of desktop applications and management capabilities for use with Portable Operating System Interface (POSIX)-based operating systems. CDE supports The Open Group Motif-based application execution. Both CDE and Motif applications use the underlying X-Windows system. The following standards are mandated for use with Portable Operating System Interface (POSIX)-compliant operating systems running (or intended to run) POSIX-compliant applications:
Currently, the CDE and Motif User Interface Service Standards are mandated; but, due to changing market conditions, they are candidates for removal in a future version of the JTA.
C323 , XCDE Services and Applications, Open Group Technical Standard, ISBN 1-85912-074-1, April 1995.
C324 , XCDE Definitions and Infrastructure, Open Group Technical Standard, ISBN 1-85912-070-9, April 1995.
C508 , Window Management (X11R5): Xlib - C Language Binding, Open Group Technical Standard, ISBN 1-85912-088-1, May 1995, as updated by X11R6.
C509 , Window Management (X11R5): X Toolkit Intrinsics, Open Group Technical Standard, ISBN 1-85912-089-X, May 1995, as updated by X11R6.
C510 , Window Management (X11R5): File Formats and Application Conventions, Open Group Technical Standard, ISBN 1-85912-090-3, May 1995.
M023 : CDE 2.1 Programmer's Overview and Guide, Open Group Product Documentation, ISBN 1-85912-183-7, October 1997.
M024A : CDE 2.1 Programmer's Reference, Volume 1, Open Group Product Documentation, ISBN 1-85912-188-8, October 1997.
M024B : CDE 2.1 Programmer's Reference, Volume 2, Open Group Product Documentation, ISBN 1-85912-193-4, October 1997.
M024C : CDE 2.1 Programmer's Reference, Volume 3, Open Group Product Documentation, ISBN 1-85912-174-8, October 1997.
User Interface Service -- Win32
User Interface API Services defines the software interfaces needed to control user interfaces with an information technology system. The Win32 API set provides User Interface Services for Microsoft Windows and Windows-compliant applications. Documentation for the Win32 APIs is found within the Microsoft Platform Software Development Kit (SDK). This documentation is mandated for use with any operating system running (or intended to run) Win32 applications:
Data Management Services
Central to most systems is the sharing of data between applications. The data management services provide for the independent management of data shared by multiple applications.
These services support the definition, storage, and retrieval of data elements from Database Management Systems (DBMSs). Application code using Relational Database Management System (RDBMS) resources and COTS RDBMSs are required to conform to Entry-Level SQL. The following standard is mandated for any system using an RDBMS:
In addition, the SQL/Call Level Interface (CLI) addendum to the SQL standard provides a standard CLI between database application clients and database servers. The following API is mandated for both database application clients and database servers:
The ISO/IEC 9075-3 mandate does not preclude the use of Open Database Connectivity (ODBC) 3.0 or Java Database Connectivity (JDBC) extensions in situations where the capabilities supported by ISO/IEC 9075-3 cannot satisfy user-functional requirements. Note that ISO/IEC 9075-3 is a subset of ODBC 3.0.
Data Interchange Services
The data interchange services provide specialized support for the exchange of data between applications and to and from the external environment. These services include document, graphics data, geospatial data, still imagery data, motion imagery data, audio data, storage media, atmospheric and oceanographic data, and time-of-day data.
Document Interchange
The Standard Generalized Markup Language (SGML) format supports the production of documents intended for long-term storage and electronic dissemination for viewing in multiple formats. SGML formalizes document mark-up, making the document independent of the production and/or publishing system. SGML is an architecture-independent and application-independent language for managing document structures. SGML is a meta-language, providing the rules for designing and applying a system of markup tags rather than the specific set of tags. The following standard is mandated:
The Hypertext Markup Language (HTML) is used for hypertext-formatted and navigational-linked documents. For hypertext documents intended to be interchanged via the Web or made available via organizational intranets, the following standard is mandated:
The Extensible Markup Language (XML) is a meta-language, based on SGML, for describing languages based on name-attribute tuples. This allows new capabilities to be defined and delivered dynamically. For domain- and application-specific markup languages defined through tagged data items, the following is a mandated standard:
See : Common Document Interchange Formats identifies file formats for the interchange of common document types such as text documents, spreadsheets, and presentation graphics. Some of these formats are controlled by individual vendors, but all of these formats are supported by products from multiple companies. In support of the standards mandated in this section, See : Common Document Interchange Formats identifies conventions for file name extensions for documents of various types. If an organization has a requirement for a given document type, the formats in See : Common Document Interchange Formats are mandated, but not the specific products mentioned:
All applications acquired or developed for the production of documents shall be capable of generating at least one of the formats listed in See : Common Document Interchange Formats for the appropriate document type.
Notes: Compound documents contain embedded graphics, tables, and formatted text. Object Linking and Embedding (OLE) linking complicates document interchange. IRV is International Reference Version. Some special fonts, formatting, or features supported in the native file format may not convert accurately.
Graphics Data Interchange
These services are supported by device-independent descriptions of the picture elements for vector and raster graphics. The International Organization for Standardization (ISO) Joint Photographic Expert Group (JPEG) standard describes several alternative algorithms for the representation and compression of raster images, particularly for imagery; JPEG images may be transferred using the JPEG File Interchange Format (JFIF). Graphics Interchange Format (GIF) and JFIF are de facto standards for exchanging graphics and images over an internet. GIF supports lossless compressed images with up to 256 colors and short animation segments. Note that Unisys owns a related patent, which requires a license for software that writes the GIF format. Portable Network Graphics (PNG) is an extensible file format for the lossless, portable, well-compressed storage of a raster image. Indexed-color, grayscale, and truecolour images are supported, plus an optional alpha channel for transparency. The PNG specification was issued as a W3C Recommendation on 1 October 1996.
For the interchange of very large still-raster images that have no geospatial context and where lossy compression is acceptable, the mandated standard is:
For the interchange of other single raster images that have no geospatial context and where lossy compression is not acceptable or is ineffective, the mandated standard is:
For the lossless interchange of raster images that have no geospatial context and where none of the above cases apply, such as the exchange of still images that can be viewed in sequence (also referred to as animation), the mandated standard is:
Geospatial Data Interchange
Geospatial services are also referred to as mapping, charting, and geodesy (MC&G) services. Raster Product Format (RPF) defines a common format for the interchange of raster-formatted digital geospatial data among DoD Components. Existing geospatial products that implement RPF include Compressed ARC Digitized Raster Graphics (CADRG), Controlled Image Base (CIB), and Digital Point Positioning Data Base (DPPDB). For raster-based products, the following standard is mandated:
Vector Product Format (VPF) defines a common format, structure, and organization for data objects in large geographic databases based on a georelational data model and intended for direct use. Existing geospatial products that implement VPF include: Vector Map (VMap) Levels 0-2, Urban Vector Map (UVMap), Digital Nautical Chart (DNC), VPF Interim Terrain Data (VITD), Digital Topographic Data (DTOP), and World Vector Shoreline Plus (WVS PLUS ). For vector-based products, the following standard is mandated:
WGS84, a Conventional Terrestrial Reference System (CTRS), is mandated for representation of a reference frame, reference ellipsoid, fundamental constants, and an Earth Gravitational Model with related geoid. Included in the Reference System are parameters for transferring to/from other geodetic datums. The National Imagery and Mapping Agency (NIMA) Technical Report (TR) 8350.2, Third Edition DoD World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems, 4 July 1997, defines the technical content of WGS 84. WGS 84 will be used for all joint operations and is recommended for use in multinational and unilateral operations after coordination with allied commands. The following standard is mandated:
FIPS PUB 10-4 provides a list of the basic geopolitical entities in the world, together with the principal administrative divisions that comprise each entity. For applications involving the interchange of geospatial information requiring the use of country codes, the following standard is mandated:
Additional information on other geospatial services not identified in the mandated standards is available in NIMAL 805-1A, NIMA GGI&S List of Products and Services, January 1997.
Still Imagery Data Interchange
The National Imagery Transmission Format Standard (NITFS) is a DoD and Federal Intelligence Community suite of standards for the exchange, storage, and transmission of digital imagery products and image-related products. Other image formats can be used internally within a single system; however, NITF is the default format for interchange between systems. NITFS provides a package containing information about the image, the image itself, and optional overlay graphics. The standard provides a "package" containing an image(s), subimages, symbols, labels, and text as well as other information related to the image(s). NITFS supports the dissemination of secondary digital imagery from overhead collection platforms. Guidance on applying the suite of standards composing NITFS can be found in MIL-HDBK-1300A. The following standards are mandated for imagery product dissemination:
MIL-STD-2500B , National Imagery Transmission Format (Version 2.1) for the National Imagery Transmission Format Standard, 22 August 1997 with Notice 1, 2 October 1998.
MIL-STD-188-196 , Bi-Level Image Compression for the National Imagery Transmission Format Standard, 18 June 1993 with Notice 1, 27 June 1996.
MIL-STD-188-199 , Vector Quantization Decompression for the National Imagery Transmission Format Standard, 27 June 1994 with Notice 1, 27 June 1996.
ISO/IEC 8632:1992 Computer Graphics Metafile (CGM) for the Storage and Transfer of Picture Description Information, as profiled by MIL-STD-2301A, Computer Graphics Metafile (CGM) Implementation Standard for the National Imagery Transmission Format Standard, 5 June 1998.
ISO/IEC 10918-1:1994 , Joint Photographic Experts Group (JPEG) as profiled by MIL-STD-188-198A, Joint Photographic Experts Group (JPEG) Image Compression for the National Imagery Transmission Format Standard, 15 December 1993 with Notice 1, 12 October 1994 and Notice 2, 14 March 1997. Although the NITFS uses the same ISO JPEG algorithm as mandated in See Graphics Data Interchange, the NITFS file format is not interchangeable with the JFIF file format.
Communication protocols for the transmission of imagery over point-to-point tactical data links in high Bit Error Rate (BER), disadvantaged communications environments are specified in See Imagery Dissemination Communications Standards.
Motion Imagery Data Interchange
Motion Imagery (MI) is defined as imaging sensors/systems that generate/process sequential or continuous streaming images at specified temporal rates (normally expressed as Frames Per Second [FPS] or hertz [Hz]) within a common field of regard. Motion Imagery defines temporal domains of 1 Hz or higher, and still imagery defines temporal domains of less than 1 Hz.
Video Systems
Video systems, defined as electro-optical motion imagery whose formats are governed by national and international standards, are divided into four categories:
Video Imagery Systems, which create, transmit, edit, store, archive, or disseminate digital video for real-time, near-real-time or for other end-user product distribution, usually in support of Intelligence, Surveillance, and Reconnaissance (ISR) activities.
Video Teleconference Systems, which provide real-time visual interchange between remote locations typically in support of meetings. When video teleconference systems are used for the display of Video Imagery, the standards in the Video Imagery section apply.
The standards and use directives for each class of video system are noted in the following sections:
Video Imagery
The following standards, as they are profiled by the Motion Imagery Standards Profile (MISP) 1.6 Chapter 2.0, Commercial Standards, Interoperability Profiles, and Recommended Practices for DoD/IC/USIGS Implementations, 27 July 2000, are mandated:
The standards for the Video Imagery section do not completely define an architecture for interoperability for low bandwidth (below 1.5 Mbps) real-time streaming applications. Standards for such low-bandwidth applications are actively under development. Until such standards are available, users may use "MPEG-1" or "MPEG-2 4:20 MP@ML Adaptive Field Frame" standards for low bandwidth video applications. DoD users who adopt proprietary video compression systems for very low bandwidth applications are cautioned that such systems are generally not supported within DoD and that the interoperability of such systems is not ensured. It is also anticipated that MPEG-4 may be used for very low data rate video dissemination applications (such as VSM 1 and VSM 2).
Video Teleconference
Video Teleconferencing (VTC) standards are specified in See Video Teleconferencing Standards.
Video Support
MPEG-1 is an open international standard for video compression that has been optimized for single- and double-speed CD-ROM data transfer rates. The standard defines a bit-stream representation for synchronized digital video and audio, compressed to fit into a bandwidth of 1.5 Mbps. This corresponds to the data retrieval speed from CD-ROM and Digital Audio Tape (DAT). With 30 FPS video at a display resolution of 352 x 240 pixels, the quality of compressed and decompressed video at this data rate is often described as similar to that of a VHS recording. A major application of MPEG is the storage of audiovisual information on CD-ROM and DAT. MPEG is also gaining ground on the Internet as an interchange standard for video clips because the shell format is interoperable across platforms and considered to be platform-independent. The following standards are mandated:
MPEG-2 Main Profile @ Main Level (MP@ML) 4:2:0 systems are fully backward-compatible with the MPEG-1 standard. MPEG-2 MP@ML can be used with all video support systems (storage, broadcast, network) at bit rates from 3 to 10 Mbps, where limited additional processing is anticipated, operating in either progressive or interlaced scan mode, optimally handling the resolution of the ITU-R 601 recommendation (i.e., 720 x 480 pixels for the luminance signal and 360 x 480 pixels for the color space). The following video support standards for compressed video are mandated:
Audio Data Interchange
Effective compression of audio data depends not only upon data compression techniques but also upon the application of a psycho-acoustic model that predicts which sounds humans are likely to be able to hear or not hear in given situations. The sounds selected for elimination depend on the bit rate available for streaming the audio data when the file is decoded and played. Therefore, the best selection of a file format depends upon the bandwidth assumed to be available on the platform that will decode the file. For audio files intended to be decoded in an environment with a target bit rate of about 56 to 64 kilobits per second (Kbps) per audio channel, the following standards are mandated:
Audio Associated with Video
The classes of audio in support of video have been subdivided into four categories:
Audio for Video Imagery Systems , which create, transmit, edit, store, archive, or disseminate audio for real-time, near-real-time, and other end-user product distribution, usually in support of Intelligence, Surveillance, and Reconnaissance (ISR) activities.
Audio for Video Teleconference Systems , which provide real-time verbal interchange between remote locations, typically in support of meetings. When video teleconference systems are used for the display of Video Imagery, the standards in the Audio for Video Imagery section apply.
Audio for Video Telemedicine Systems , which provide real-time visual interchange between remote locations in support of biomedical applications including fiber-optic and video teleconferencing.
Audio for Video Support Systems , which enable end-user applications associated with video/audio-based training, news gathering, or other non-critical functions that do not directly support the warfighter. This includes traditional studio and field productions not associated with DoD warfighting operations.
The standards and use directives for each category of audio application are given in the following sections.
Audio for Video Imagery
For audio systems associated with Video Imagery applications, the audio sub-sections of the Video Imagery Standards Profile (VISP), Version 1.5, 8 September 1999, apply.
Audio for Video Teleconference
Video Teleconferencing (VTC) standards are specified in See Video Teleconferencing Standards.
Audio for Video Support
Effective compression of audio data depends not only upon data compression techniques but also upon the application of a psycho-acoustic model that predicts which sounds humans are likely to be able to hear or not hear in given situations. The sounds selected for elimination depend on the bit rate available for streaming the audio data when the file is decoded and played. Therefore, the best selection of a file format depends upon the bandwidth assumed to be available on the platform that will decode the file. For audio files intended to be decoded in an environment with a target bit rate of about 56 to 64 Kbps per audio channel, the following standard is mandated:
Voice Encoder
The 2.4 Kbps Mixed Excitation Linear Prediction (MELP) algorithm specified in MIL-STD-3005 is intended to provide seamless interoperability, hence enabling end-to-end security, across the domains of strategic, tactical, satellite communications, including that of internetworking protocols. MIL-STD-3005 provides a common high-performance voice encoding algorithm for use across the communications infrastructure. For processing over 2.4 Kbps digital links (voice data), the following standard is mandated:
Data Interchange Storage Media
MIL-HDBK-9660B, 1 September 1997, provides additional guidance in the use of Compact Disc-Read Only Memory (CD-ROM) technology. In cases where CD-ROM/CD-RW media is used, the following file system format (at a minimum) is mandated:
Additional standards used for the exchange of multimedia data can be found in See Video Teleconferencing Standards.
Atmospheric and Oceanographic Data Interchange
The following formats are established by the World Meteorological Organization (WMO) Commission for Basic Systems (CBS) for atmospheric and oceanographic data. The WMO Format for the Storage of Weather Product Information and the Exchange of Weather Product Messages in Gridded Binary (GRIB) Form was developed for the transfer of gridded data fields, including spectral model coefficients, and of satellite images. A GRIB record (message) contains values at grid points of an array, or a set of spectral coefficients, for a parameter at a single level or layer as a continuous bit stream. It is an efficient vehicle for transmitting large volumes of gridded data to automated centers over high-speed telecommunications lines using modern protocols. It can serve as a data storage format. While GRIB can use predefined grids, provisions have been made for a grid to be defined within the message. The following standard is mandated:
The WMO Binary Universal Format for Representation (BUFR) is used for interchange of atmospheric and oceanographic data. Besides being used for the transfer of data, BUFR is used as an online storage format and as a data-archiving format. A BUFR record (message) containing observational data of any sort also contains a complete description of what those data are: the description includes identifying the parameter in question (height, temperature, pressure, latitude, date, and time); the units (any decimal scaling that may have been employed to change the precision from that of the original units); data compression that may have been applied for efficiency; and the number of binary bits used to contain the numeric value of the observation. BUFR is a purely binary or bit-oriented form. The following standard is mandated:
Time-of-Day Data Interchange
Coordinated Universal Time (UTC), traceable to UTC (USNO) maintained by the U.S. Naval Observatory (USNO), shall be used for time-of-day information exchanged among DoD systems. Time-of-day information is exchanged for numerous purposes including time-stamping events, determining ordering, and synchronizing clocks. Traceability to UTC (USNO) may be achieved by various means depending on system-specific accuracy requirements. These means may range from a direct reference via a GPS time code receiver to a manual interface involving an operator, wristwatch, and telephone-based time service. The UTC definition contained in the following standard, traceable to UTC (USNO), is mandated:
In those systems where relativistic effects matter, the following standard is mandated:
Note that the Global Positioning System (GPS) provides time-of-day information traceable to UTC (USNO). Also, note that leap seconds are inserted or deleted when necessary in UTC to keep the time-of-day system synchronized with the Earth's rotation. See Paragraph for a GPS discussion, required standards, and guidelines.
Graphic Services
These services support the creation and manipulation of graphics. The following standards are mandated for non-COTS graphics development:
Communications Services
These services support the distributed applications that require data access and applications interoperability in networked environments. The mandated standards are provided in See Information Transfer Standards.
Operating System Services
These core services are necessary to operate and administer a computer platform and to support the operation of application software. They include kernel operations, shell, and utilities. The operating system controls access to information and the underlying hardware. These services shall be accessed by applications through either the standard Portable Operating System Interface (POSIX) or Win32 APIs.
When requiring real-time operating systems, the IEEE 1003.13:1998 Standardized Application Environment Profile - POSIX Realtime Application Support standard should be considered for use. It has been designed to satisfy a wide range of real-time system requirements based upon the Application Platform's size and function. It identifies four real-time application environment profiles based on the ISO/IEC 9945-1 series of standards including: Minimal Realtime System Profile (PSE51), Realtime Controller System Profile (PSE52), Dedicated Realtime System Profile (PSE53), and Multi-Purpose Realtime System Profile (PSE54).
Not all operating system services are required to be implemented, but those that are used shall comply with the standards listed below. The following standards are mandated:
Note: References to "C language" and "Ada language" are part of the formal titles of some standards in this section, denoting the language used to define the standard. The following standards are mandated for use with POSIX-compliant operating systems running (or intended to run) POSIX-compliant applications:
ISO/IEC 9945-1:1996 , Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C language] (Mandated Services).
ISO/IEC 9945-1:1996 , (Real-time Extensions) to ISO/IEC 9945-1:1996, Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C language] (Real-time Optional Services).
ISO/IEC 9945-1:1996 , (Thread Extensions) to ISO/IEC 9945-1:1996, Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C language] (Thread Optional Services).
ISO/IEC 9945-2:1993 , Information Technology Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities, Information Technology - Portable Operating System Interface (POSIX) - Recommendations (Section 12) and Implementation Guidance (Section 13).
Documentation for the Win32 APIs is found within the Microsoft Platform SDK. This documentation is mandated for use with any operating system running (or intended to run) Win32 applications:
Internationalization Services
The internationalization services provide a set of services and interfaces that allow a user to define, select, and change between different culturally related application environments supported by the particular implementation. These services include character sets, data representation, cultural convention, and native-language support.
In order to interchange text information between systems, it is fundamental that systems agree on the character representation of textual data. The following character set coding standards, which build upon the ASCII character set, are mandated for the interchange of 8-bit and 16-bit textual information respectively:
Security Services
These services assist in protecting information and computer platform resources. They must often be combined with security procedures, which are beyond the scope of the information technology service areas, to fully meet security requirements. Security services include security policy, accountability, and assurance. (Note: Security Service standards have been consolidated in See Information Security Standards)
System Management Services
These services provide capabilities to manage an operating platform and its resources and users. System management services include configuration management, network management, fault management, and performance management. The JTA facilitates interoperability by identifying network management standards. These standards can be found in sections See Network and Systems Management and See Network Management.
Distributed Computing Services
These services allow various tasks, operations, and information transfers to occur on multiple physically or logically dispersed computer platforms. These services include, but are not limited to: global time; data, file, and name services; thread services; and remote-process services. There are two categories of Distributed Computing Services: Remote-Procedure Computing and Distributed-Object Computing.
Remote-Procedure Computing
The mandated standards for remote-procedure computing are identified in the Open Group Distributed Computing Environment (DCE) Version 1.1. The mandated standards are:
The C311 specification is included here to provide the complete definition of the DCE. See Information Security Standards, Information Security Standards, specifies the other security requirements that must be met.
When used in conjunction with the POSIX Threads Extensions, the recommendations of the Open Group's Single UNIX Specification Version 2 - 6 Vol Set for UNIX 98 are expected to integrate the DCE thread model with the POSIX thread model.
Distributed-Object Computing
The mandate for distributed-object computing is interworking with the Object Management Group (OMG) Object Management Architecture (OMA), composed of the Common Object Request Broker Architecture (CORBA), CORBAservices, and CORBAfacilities. The CORBA specification defines the interfaces and services for Object Request Brokers, including an Interface Definition Language (IDL) and the Internet Inter-ORB Protocol (IIOP). CORBAservices define interfaces and semantics for services required to support distributed objects, such as naming, security, transactions, and events. CORBAfacilities defines interfaces and semantics for services required to support functions such as compound document manipulation. Interworking is the exchange of meaningful information between computing elements (semantic integration). Application-Level Interworking, for CORBA, results in CORBA clients interacting with non-CORBA servers and non-CORBA clients interacting with CORBA servers. For OLE/COM, Application-Level Interworking results in COM/OLE clients interacting with non-COM/OLE servers and non-COM/OLE clients interacting with COM/OLE servers.
The CORBA interoperability mandate does not preclude the use of other distributed-object technologies, such as ActiveX/Distributed Component Object Model (DCOM) or Java, as long as the capability for interworking with CORBA applications and objects is maintained by the non-CORBA system. Products are available that allow interworking among distributed-object techniques. Interworking with the following specification is mandated:
When a CORBA Object Request Broker (ORB) is used, the following specifications are mandated if the corresponding object service is being implemented:
For DCE users that need to interwork with CORBA, the following standard is mandated:
For COM users that need to interwork with CORBA, the following standards are mandated:
Emerging Standards
Emerging standards are expected to be elevated to mandatory status when implementations of the standards mature and the standards meet all criteria in See Standards Selection Criteria.
Data Management
Parts one through five of the emerging SQL3 specification were completed in December 1999 and contain a number of data abstraction facilities, including user-defined data types and methods. The emerging SQL specification also contains facilities for defining and referencing object identifiers. Additionally, the emerging SQL3 specification supports knowledge-based data management and remote data access capabilities. The following SQL3 standards are emerging and have been completed and approved by ANSI, ISO, and IEC:
ANSI/ISO/IEC 9075-1:1999 , Information technology - Database languages - SQL - Part 1: Framework (SQL/Framework).
ANSI/ISO/IEC 9075-2:1999 , Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation).
ANSI/ISO/IEC 9075-3:1999 , Information technology - Database languages - SQL - Part 3: Call-Level Interface (for SQL3).
Additionally, ISO/IEC DIS 9075-9 through ISO/IEC DIS 9075-12 are in progress though they have not been completed.
SQL Multimedia (SQL/MM) is a set of extensions to the SQL3 specification and will specify packages of SQL abstract data type (ADT) definitions using the facilities for ADT specification and invocation provided in the SQL3 specification. SQL/MM intends to standardize class libraries for science and engineering; full-text and document processing; and methods for the management of multimedia objects such as image, sound, animation, music, and video. The emerging standard for SQL/MM is:
The SQL - RDA standard specifies a message format for remote communication of SQL database language statements (query and update) to a remote database. The specification defines uses of the message fields and other implementation information including sequencing and how SQL statements map to the Remote Database Access (RDA) protocol, a TCP/IP-compatible communications protocol that enables a database client to gain access to database servers. The emerging standard for SQL - RDA is:
The Object Database Management Group (ODMG) has published a third version of their standard for an Object Storage API that can work with any DBMS or tool. The ODMG has defined a comprehensive object model, described an object specification language, defined an object interchange format, defined an object query language (based on the relational query language, SQL) and worked to make the programming language bindings consistent with the ODMG model. Version 3.0 improves the ODMG model, enhances the Java bindings, and broadens the standard for use by object-relational mapping systems as well as for object DBMSs. The ODMG specification is published as a hard-cover book. The following standard is emerging:
Data Interchange
Document Interchange
XHTML (Extensible HyperText Markup Language) is the next-generation follow-on to HTML. XHTML reformulates HTML as an XML (Extensible Markup Language) application, bringing the modular capabilities of XML to Web development. A single XML data stream can be used by a variety of applications to support multiple devices, such as cellular telephones, computers, Web television, and embedded applications simply by processing the needed XHTML tags within the XML data stream. The following standard is emerging:
XForms architecture separates purpose (semantics) from presentation (syntax), and associates the capabilities of XML and the ease of HTML for a wide range of devices. The following standards are emerging:
Resource Description Framework (RDF) describes a foundation for processing WWW metadata; it supports interoperability between different applications that may need to exchange machine-understandable information on the WWW. RDF uses Extensible Markup Language (XML) for encoding its interchange syntax. RDF is a model for representing named properties (attributes of resources), property values, and relationships between properties. An RDF model can resemble an entity-relationship diagram or virtually any other information structure that can be depicted as a directed graph. The following standard is emerging:
The RDF Schema specification provides a machine-understandable system for defining "schemas" for descriptive vocabularies like the Dublin Core, a set of 15 metadata elements believed to be broadly applicable to describing Web resources to enable their discovery. It allows designers to specify classes of resource types and properties to convey descriptions of those classes, and constraints on the allowed combinations of classes, properties, and values within a data stream. This has the effect of providing a machine-understandable means of exchanging structured and structural information with respect to various persistent entities, such as DBMSs with XML. The following standard is emerging:
A Working Draft of the Extensible Stylesheet Language (XSL) Version 1.0 (Ref: WD-xsl-19981216, 16 December 1998) is being defined in the World Wide Web Consortium. XSL will be used where powerful formatting capabilities are required or for formatting highly structured information such as XML-structured data or XML documents that contain structured data. The new capabilities provided by the XSL proposal include: the formatting of source elements based on ancestry/descendency, position, and uniqueness; the creation of formatting constructs including generated text and graphics; the definition of reusable formatting macros; direction-writing, independent stylesheets; and extensible set of formatting objects.
XSL uses XML syntax and combines formatting features from Document Style and Semantics Specification Language (DSSSL). The following standard is emerging:
XML Stylesheet Language Transformations (XSLT) is a language for transforming XML documents into other XML documents and is used as a transformation part of XSL. XSLT has also been designed to be used independently, but is used primarily with XSL. The following standard is emerging:
XPath is a language for addressing parts of an XML document, designed to be used by XSLT. The following standard is emerging.
Graphics Data Interchange
Virtual Reality Modeling Language
The Virtual Reality Modeling Language (VRML) is a commercial standard with capabilities for 3-D representation of data. The following standard is emerging:
Multiple-Image Network Graphics
The Multiple-image Network Graphics (MNG) format is an extension to the PNG format, developed by the PNG Development Group, for the storage and transmission of animated graphics and complex still images. It was designed to replace GIF animation with a true animation format. The design was frozen in May 1999. The working document is MNG (Multiple-image Network Graphics) Format, PNG Development Group, 1999.
Still Imagery Data Interchange
The Basic Image Interchange Format (BIIF) is a published international standard. It provides a commercial/international foundation for interoperability in the interchange of imagery and imagery-related data among applications. BIIF provides a data format container for image, symbol, and text, along with a mechanism for including image-related support data. The following standard is emerging:
Part I of JPEG 2000 Image Coding System has been approved as an International Standard. JPEG 2000 is intended to provide a new means of image representation containing a rich set of features, all supported within the same compressed bit stream. The following standard is emerging:
Motion Imagery Data Interchange
Video Systems
Video Imagery
The following standards, as they are profiled by the Motion Imagery Standards Profile (MISP) 1.6, Chapter 2.0, Commercial Standards, Interoperability Profiles, and Recommended Practices for DoD/IC/USIGS Implementations, 27 July 2000, are emerging:
The following standard is emerging for advanced television applications:
Video Teleconference
Emerging standards for video teleconferencing are covered in the Information Transfer section of the JTA, See Video Teleconferencing Standards.
Multimedia Data Interchange
The "Draft DoD Guide to Selecting Computer-Based Multimedia Standards, Technologies, Products, and Practices," dated 15 February 1998, defines emerging standards for DoD systems employing multimedia. In this context, interactivity is a key distinguishing characteristic, in which "two or more media types (audio, video, imagery, text, and data) are electronically manipulated, integrated, and reconstructed in synchrony, where interactivity indicates an ability of a user to make decisions or selections that (can) alter the type and sequence of information or communication."
Voice Encoder
The 1.2 Kbps enhanced Mixed Excitation Linear Prediction (MELP) algorithm is based upon MIL-STD-3005 and is intended to extend seamless interoperability to bandwidth limited users (HF links, MILSATCOMs, covert ops, etc.), hence enabling end-to-end security to this user community. MIL-STD-3005 provides a common high-performance voice-encoding algorithm for use across the communications infrastructure and will be included in the current MIL-STD-3005 as an annex. For processing voice data at rates under 2.4 Kbps, the following standard is emerging:
POSIX Operating Systems
The following POSIX standards are emerging:
P1003.1a , Draft Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language] - Amendment, Draft 16, December 1998.
IEEE 1003.1d:1999 , Standard for Information Technology - Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) - Amendment d: Additional Realtime Extensions [C Language].
IEEE 1003.1j:2000 , Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) - Amendment j: Advanced Realtime Extensions [C Language].
P1003.1m , Draft Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) - Amendment m: Checkpoint/Restart Interface [C Language], Draft 2, January 1999.
P1003.1q , Draft Standard for Information Technology - Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) - Amendment x: Tracing [C Language], Draft 8, April 2000.
P1003.5g/D1 , Standard for Information Technology - Portable Operating System Interface (POSIX) - Ada Language Interfaces - Part 1: Binding for System Application Program Interface (API) -Amendment g: Realtime Extensions, September 1999.
P1003.13a/D1 , Standard for Information Technology - Standardized Application Environment Profile - POSIX Realtime Application Support (AEP) - Amendment a: Realtime Extension, September 1999.
In addition, the sponsor committee for POSIX standards (Portable Application Standards Committee), the international POSIX standards working group (JTC1/SC22/WG15), and The Open Group (TOG) are seeking to approve a new IEEE and ISO standards project to revise and consolidate those standards that make up ISO/IEC 9945-1:1996 and ISO/IEC 9945-2:1993 plus any additional supplements to those standards that are already IEEE standards or became IEEE standards by 31 December 1999.
Once this revision is approved by all three bodies, the ISO POSIX standard, the IEEE POSIX standards, and the Single UNIX Specification (SUS) will be identical in all respects. For more information, see: <http://www.opengroup.org/austin/docreg.html> .
Distributed Computing Services
Distributed-Object Computing
The CORBA 3 suite of specifications are divided into three major categories: Internet Integration; Quality of Service Control; and the CORBAcomponent architecture. The following CORBA 3 suite of specifications are emerging:
The following distributed-object computing specifications from the Object Management Group (OMG) are emerging:
Support Application Services
Environment Management
DoD 5015.2-STD, Design Criteria Standard for Electronic Records Management Software Applications, Sections 2.2.1 through 2.2.11, provides a mandatory baseline set of requirements for Records Management Application (RMA) software. RMA software may be used by DoD Components in the implementation of records management programs. Each official Component record is defined by an approved Records Control Schedule (RCS). If a Component chooses to maintain official records in an electronic form, those records must be managed by application(s) consistent with this standard. Future versions of this standard will address interoperability requirements. The following standard is emerging:
Learning Technology
Learning Technology standards provide for an integrated environment for education, training, and decision support and are considered a subset of the Environment Management services within the DoD TRM. A growing number of technical standards for this field are in varying stages of development by standards bodies including the following, each of which can be accessed on the Web at the URL indicated:
The following standards are being tracked as Learning Technology emerging standards:
IEEE 1484.1 , Architecture and Reference Model Working Group Document: "Learning Technology Systems Architecture (LTSA), Draft 5, 1999-12-08".
IEEE P1484.2 , Learner Model Working Group Document "Public and Private Information (PAPI) for Learners, Draft Version 6, 2000-06-23".
Information Transfer Standards
Introduction
Purpose
Information Transfer standards and profiles are described in this section. These standards promote seamless communications and information transfer interoperability for DoD systems.
Scope
This section identifies the information transfer standards required for interoperability between DoD information technology systems. These standards support access for end-systems including host, Video Teleconferencing (VTC), facsimile, Global Positioning System (GPS), and secondary imagery dissemination. Networking and internetworking standards are identified. Transmission media standards for MILSATCOM, Synchronous Optical Network (SONET), and radio links as well as network and systems management standards for data communications and telecommunications are identified. Finally, emerging technologies that should be monitored for future extension of information transfer capabilities are identified. This section includes the Communications Services depicted in See : DoD Technical Reference Model (DoD TRM), DoD Technical Reference Model. Security standards are addressed in See Information Transfer Security Standards.
Background
The standards are drawn from widely accepted commercial standards that meet DoD requirements. Where necessary for interoperability, profiles of commercial standards are used. Military standards are mandated only when suitable commercial standards are not available. For example, the JTA makes use of the open-systems architecture used by the Internet and the Defense Information System Network (DISN). System components are categorized here as end-systems, networks, and transmission media. End-systems (e.g., host computers, terminals) generally execute applications on behalf of users and share information with other end-systems via networks. Networks may be relatively simple (e.g., point-to-point links or subnetworks that are homogenous in protocol stacks) or have complex internal structures of diverse subnetworks. Routers interconnect two or more subnetworks and forward packets across subnetwork boundaries. Routers are distinct from hosts in that they are normally not the destination of data traffic. End-systems and networks are connected by transmission media.
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for information transfer. Each mandated standard or practice is clearly identified on a separate bulleted line and includes a formal reference that can be included within Requests for Proposals (RFPs) or Statements of Work (SOWs).
Communications
End-System Standards
This section addresses standards for the following types of end-systems: host, VTC, facsimile, imagery dissemination, and GPS.
Host Standards
Hosts are computers that generally execute application programs on behalf of users and share information with other hosts. Internet Engineering Task Force (IETF) Standard 3 is an umbrella standard that references other documents and corrects errors in some of the referenced documents. IETF Standard 3 consists of Request for Comments (RFC) 1122 and RFC 1123. This pair of documents defines and discusses the requirements for host system implementations of the Internet Protocol suite. RFC 1122 covers the communications protocol layers (link layer, IP layer, and transport layer). RFC 1123 covers the application layer protocols. The following standard is mandated:
Application Support Services
Electronic Mail
The standard for official organizational-messaging traffic between DoD organizations is the Defense Message System's (DMS's) X.400-based suite of military messaging standards defined in Allied Communications Publication (ACP) 123. The ACP 123 annexes contain standards profiles for the definition of the DMS "Business Class Messaging" (P772) capability and the Message Security Protocol (MSP). Organizational messaging is considered a high-assurance messaging service that requires authentication, delivery confirmation, and encryption. See See Information Security Standards for security standards. Since X.400 is not an Internet standard, see See Open Systems Interconnection Transport Over IP-Based Networks for operation over Internet Protocol (IP)-based networks. The following standards are mandated:
DMS has expanded its baseline to include a medium-assurance messaging service. The requirements for medium-assurance messaging are less stringent than organizational messaging and can be met by existing IP-based mail standards. This allows the augmentation of DMS to include the use of the Simple Mail Transfer Protocol (SMTP) for medium-assurance messaging. For SMTP, the following standards are mandated:
Directory Services
X.500 Directory Services
International Telecommunications Union (ITU) X.500 provides directory services that may be used by users or host applications to locate other users and resources on the network. While it is appropriate for all grades of service, it must be used for high-grade service where standards-based access control, signed operations, replication, paged results, and server-to-server communication are required. It provides the security services used by DMS-compliant X.400 implementations and is mandated for use with DMS. See See Information Security Standards for security standards. Since X.500 is not an Internet standard, see See Open Systems Interconnection Transport Over IP-Based Networks for operation over IP-based networks. The following standard is mandated:
Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP) (Version 2) is an Internet protocol for accessing online directory services. It runs directly over Transmission Control Protocol (TCP). LDAP derives from the X.500 Directory Access Protocol (DAP). It is appropriate for systems that need to support a medium grade of service in which security is not an issue, and access is only needed to a centralized server. The following standard is mandated:
Domain Name System
Domain Name System (DNS) is a hierarchical host management system that has a distributed database. It provides the look-up service of translating between host names and IP addresses. DNS uses TCP/User Datagram Protocol (UDP) as a transport service when used in conjunction with other services. Dynamic DNS enables the automation of DNS updating by introducing a new messaging mechanism to selectively insert or delete new entries into or from the DNS database. The following standards are mandated:
File Transfer
Basic file transfer is accomplished using the File Transfer Protocol, which provides a reliable file transfer service for text or binary file. FTP uses TCP as a transport service. The following standard is mandated:
Remote Terminal
For ASCII text-oriented remote-terminal services, Telecommunications Network (TELNET) provides a virtual terminal capability that allows a user to "log on" to a remote system as though the user's terminal were directly connected to the remote system. The following standard is mandated:
Network Time Synchronization
Network Time Protocol (NTP) provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet. The following standard is mandated:
Bootstrap Protocol
Bootstrap Protocol (BOOTP) is used to provide address determination and bootfile selection. It assigns an IP address to workstations with no IP address. The following standards are mandated:
Configuration Information Transfer
The Dynamic Host Configuration Protocol (DHCP) provides an extension of BOOTP to support the passing of configuration information to Internet hosts. DHCP consists of two parts: a protocol for delivering host-specific configuration parameters from a DHCP server to a host, and a mechanism for automatically allocating IP addresses to hosts. The following standard is mandated:
Web Services
Hypertext Transfer Protocol
Hyptertext Transfer Protocol (HTTP) is used for search and retrieval within the Web. The following standard is mandated:
Uniform Resource Locator
A Uniform Resource Identifier (URI) is a string identifying an abstract or physical resource on a network. Uniform Resource Locators (URLs) are the subset of URIs that identify resources via their network "location." URIs (particularly URLs) are used extensively on the Internet. RFC 2396 defines the generic syntax of URIs, while RFC 1738 defines the syntax for specific URL schemes (such as http: and ftp:). For the syntax of URIs and URLs, the following standards are mandated:
Transport Services
The transport services provide host-to-host communications capability for application support services. The following sections define the requirements for this service.
Transmission Control Protocol/User Datagram Protocol Over Internet Protocol
Transmission Control Protocol
Transmission Control Protocol (TCP) provides a reliable connection-oriented transport service. The following standards are mandated:
User Datagram Protocol
User Datagram Protocol (UDP) provides an unacknowledged, connectionless datagram transport service. The following standard is mandated:
Internet Protocol
Internet Protocol (IP) is a basic connectionless datagram service. All protocols within the IP suite use the IP datagram as the basic data transport mechanism. Two other protocols are considered integral parts of IP: the Internet Control Message Protocol (ICMP) and the Internet Group Management Protocol (IGMP). ICMP is used to provide error reporting, flow control, and route redirection. IGMP provides multicast extensions for hosts to report their group membership to multicast routers. RFC 2236, IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership. The following standards are mandated:
Furthermore, for hosts that transmit or receive multi-addressed datagrams over Combat Net Radio (CNR), the multi-addressed IP option field must be used. The following standard is mandated:
Open Systems Interconnection Transport Over IP-Based Networks
This protocol provides the interworking between Transport Protocol Class 0 (TP0) and TCP transport service necessary for Open Systems Interconnection (OSI) applications to operate over IP-based networks. The following standard is mandated:
Video Teleconferencing Standards
The ASD (C3I) mandated Federal Telecommunications Recommendation (FTR) 1080A-1998 Video Teleconferencing Profile (VCP) identifies ITU-T H.320 as the key standard to provide interoperability between Video Teleconferencing (VTC) terminal equipment, both point-to-point and multipoint configurations operating at data rates of 56-1,920 Kilobits per second (Kbps). ITU-T H.320, Narrow Band Visual Telephone Systems and Terminal Equipment, July 1997, is an umbrella standard of recommendations addressing audio, video, signaling, and control. Also in the FTR is ITU-T T.120, Transmission Protocols for Multimedia Data, July 1996, which references a family of standards for applications implementing the features of audiographic conferencing, facsimile, still image transfer, annotation, pointing, whiteboard, file transfer, audiovisual control, and application sharing.
For Video Teleconferencing Units (VTUs) and Multipoint Control Units (MCUs) operating at rates of 56 Kbps to 1,920 Kbps, except for operation over packet-based TCP/IP networks, the following standards, as they are profiled by FTR 1080A-1998, Appendix A, Video Teleconferencing Profile, October 1998, are mandated:
For applications implementing the features of audiographic conferencing, facsimile, still image transfer, annotation, pointing, whiteboard, file transfer, audiovisual control, and application sharing, operating at data rates of 9.6 to 1,920 Kbps, or operating over LANs, the following standards are mandated:
ITU-T T.81 , Information Technology - Digital Compression and Coding of Continuous-tone Still Images - Requirements and Guidelines, September 1992.
ITU-T T.82 , Information Technology - Coded Representation of Picture and Audio Information - Progressive Bi-level Image Compression, March 1993.
ITU-T T.122 , Multipoint Communications Service for Audiographic and Audio Visual Conferencing Service Definition, March 1993.
ITU-T T.123 , Protocol Stacks for Audiographic and Audiovisual Teleconferencing Applications, November 1994.
ITU-T T.124 , Generic Conference Control for Audiographic and Audiovisual Terminals and Multipoint Control Units, August 1995.
For VTC terminals operating within IP Packet Networks, the following standard is mandated:
ITU-T H.323 , Packet-based Multimedia Communications Systems, February 1998. For all other implementations of H.323, such as used over wide area networks where bandwidth, quality of service, and scalability may not be sufficient for IP-based video conferencing, see emerging standards paragraph See Video Teleconferencing Standards.
For VTC terminals operating at low bit rates (9.6 to 28.8 Kbps) the following standard is mandated:
For inverse multiplexers connected to VTC terminals, and for VTC terminals with built-in inverse multiplexers, the following standard is mandated:
For information on the ASD (C3I) VTC guidance and the Federal Telecommunications Recommendation (FTR) 1080A-1998 Video Teleconferencing Profile, see URL: <http://www.ncs.gov/n6> and URL: <http://disa.dtic.mil/disnvtc> .
Facsimile Standards
Analog Facsimile Standards
For facsimile (analog output) standards that comply with the ITU-T Group 3 specifications, the following standards are mandated:
Digital Facsimile Standards
Digital facsimile equipment standards for Type I and/or Type II modes are used for digital facsimile terminals operating in tactical, high Bit Error Rate (BER) environments and for facsimile transmissions utilizing encryption or interoperability with NATO countries. The following standard is mandated:
Imagery Dissemination Communications Standards
The Tactical Communications Protocol 2 (TACO2) is the communications component of the National Imagery Transmission Format Standard (NITFS) suite of standards used to disseminate secondary imagery. TACO2 is used over point-to-point tactical data links in high-BER disadvantaged communications environments. TACO2 is used to transfer secondary imagery and related products in which JTA transfer protocols in See Transport Services fail (e.g., TACO2 only applies to users having simplex and half-duplex links as their only means of communications). MIL-HDBK-1300A, NITFS, provides guidance to implement various Technical Interface Specifications (TISs) to connect the TACO2 host to specific cryptographic equipment. The following standard is mandated:
Global Positioning System
The CJCS (CJCSI 6130.01A, 1998 CJCS Master Positioning, Navigation, and Timing Plan) has declared that the GPS will be the primary radionavigation system source of positioning, navigation and timing (PNT) for DoD. GPS is a space-based, worldwide, precise positioning, velocity, and timing system. It provides an unlimited number of suitably equipped passive users with a force-enhancing, common-grid, all-weather, continuous, three-dimensional PNT capability. The NAVSTAR GPS provides two levels of service--a Standard Positioning Service (SPS) and a Precise Positioning Service (PPS). The following standard is mandated:
The PPS was designed primarily for U.S. military use, and DoD will control access to the PPS through cryptography. DoD GPS users with combat, combat support, or combat service support missions must acquire and use PPS-capable GPS receivers. The U.S. will enter into special arrangements with military users of allied and friendly governments to allow them use of the PPS. The following standards are mandated:
The United States discontinued the use of Selective Availability (SA); or in other words, SA errors were set to zero (e.g., SA=0). ASD(C3I) issued SA=0 policy and affirmed that Navigation Warfare (NAVWAR) is now the preferred method to prevent adversary use of GPS. NAVWAR is used to deny, degrade, and otherwise disrupt GPS Standard Positioning Service (SPS) within a theater of operations. This policy further states that it is imperative that DoD users incorporate properly keyed Precise Positioning Service receivers unless a waiver to use SPS is obtained.
For additional information associated with the acquisition and use of PPS-capable GPS receivers, including end-of-week rollover compliance, consult the GPS JPO.
Network Standards
Networks are made up of subnetworks, and the internetworking (router) elements needed for information transfer. This section identifies the standards needed to access certain subnetworks and for routing and interoperability between the subnetworks.
Internetworking (Router) Standards
Routers are used to interconnect various subnetworks and end-systems. Protocols necessary to provide this service are specified below. RFC 1812 is an umbrella standard that references other documents and corrects errors in some of the referenced documents. In addition, some of the standards mandated for hosts in See Host Standards also apply to routers. The following standards are mandated:
Security requirements are addressed in See Information Security Standards.
Internet Protocol
Internet Protocol (IP) is a basic connectionless datagram service. All protocols within the IP suite use the IP datagram as the basic data transport mechanism. IP was designed to interconnect heterogeneous networks and operates over a wide variety of networks. Two other protocols are considered integral parts of IP: ICMP and IGMP. ICMP is used to provide error reporting, flow control, and route redirection. IGMP provides multicast extensions for hosts to report their group membership to multicast routers. IETF RFC 2236, IGMP Version 2, is used by IP hosts to report their multicast group memberships to routers. It updates IETF Standard RFC 1112. IGMP Version 2 allows group membership termination to be quickly reported to the routing protocol, which is important for subnets with highly volatile group membership and high bandwidth multicast group.The following standards are mandated:
In addition, in all implementations of IP routers that transmit or receive multi-addressed datagrams over CNR, the multi-addressed IP option field must be used. The following standard is mandated:
Internet Protocol Routing
Routers exchange connectivity information with other routers to determine network connectivity and adapt to changes in the network. This enables routers to determine, on a dynamic basis, where to send IP packets.
Interior Routers
Routes within an autonomous system are considered local routes that are administered and advertised locally by means of an interior gateway protocol. For unicast interior gateway routing, the following standard is mandated:
Subnetworks
This section identifies the standards needed to access subnetworks used in joint environments.
Local Area Network Access
While no specific Local Area Network (LAN) technology is mandated, the following is required for interoperability in a joint environment. This requires provision for a LAN interconnection. Ethernet, the implementation of Carrier Sense Multiple Access with Collision Detection (CSMA/CD), is the most common LAN technology in use with TCP/IP. The hosts use a CSMA/CD scheme to control access to the transmission medium. An extension to Ethernet, Fast Ethernet provides interoperable service at both 10 Mbps and 100 Mbps. Higher-speed interconnections are provided by 100BASE-TX (two pairs of Category 5 unshielded twisted pair, with 100BASE-TX Auto-Negotiation features employed to permit interoperation with 10BASE-T). For platforms physically connected to a Joint Task Force LAN, the following standards are mandated as the minimum set for operation in a Joint Task Force:
ISO/IEC 8802-3:1996 , Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, 10BASE-T Medium-Access Unit (MAU).
IEEE 802.3u:1995 , Supplement to ISO/IEC 8802-3:1993, Local and Metropolitan Area Networks: Media Access Control (MAC) Parameters, Physical Layer, Medium Attachment Units, and Repeater for 100 Mbps Operation, Type 100BASE-T (Clauses 21-30).
Point-to-Point Standards
For full duplex, synchronous or asynchronous, point-to-point communication, the following standards are mandated:
For the serial line interface, one of the following is mandated:
Combat Net Radio Networking
Combat Net Radios (CNRs) are a family of radios that allow voice or data communications for mobile users. These radios provide a half-duplex broadcast transmission media with potentially high BERs. The method by which IP packets are encapsulated and transmitted is specified in MIL-STD-188-220B. With the exception of High Frequency (HF) networks, MIL-STD-188-220B shall be used as the standard communications net access protocol for CNR networks. The following standard is mandated:
Integrated Services Digital Network
Integrated Services Digital Network (ISDN) is an international standard used to support integrated voice and data over standard twisted-pair wire. ISDN defines a Basic Rate Interface (BRI) and Primary Rate Interface (PRI) to provide digital access to ISDN networks. These interfaces support both circuit-switched and packet-switched services. It should be noted that deployable systems might additionally be required to support other non-North American ISDN standards when accessing region-specific international infrastructure for ISDN services. The JTA recognizes that this is a critical area affecting interoperability but does not recommend specific solutions in this version. The following standards are mandated:
For signaling at the user-network interface:
ANSI T1.607-1998 , Digital Subscriber Signaling System No. 1 (DSS1) - Layer 3 Signaling Specification for Circuit Switched Bearer Service, 1998.
ANSI T1.610-1998 , DSS1 - Generic Procedures for the Control of ISDN Supplementary Services, 1998.
For signaling at node-to-node interface:
For transmitting IP packets when using ISDN packet-switched services:
For transmitting IP packets using Point-to-Point Protocol (PPP) over ISDN:
Asynchronous Transfer Mode
Asynchronous Transfer Mode (ATM) is a high-speed switched data transport technology that takes advantage of primarily low BER transmission media to accommodate intelligent multiplexing of voice, data, video, and composite inputs over high-speed trunks and dedicated user links. ATM is a layered type of transfer protocol with the individual layers consisting of an ATM Adaptation Layer (AAL), the ATM layer, and the Physical Layer. The function of the AAL layer is to adapt any traffic (video streams, data packets from upper layer protocols) into the ATM format of 48-octet payload. It also receives the cells from the ATM layer and reassembles the protocol data units. The ATM Layer adds the necessary header information used by switches and end-systems alike to transfer cells across the ATM network. The Physical Layer converts the cell information to the appropriate electrical/optical signals for the given transmission medium. The ATM Forum's User-Network Interface (UNI) Specification defines the primary specification for end-system connection to ATM networks. The Private Network-Network Interface (PNNI) Specification defines the PNNI protocol for use between private ATM switches, and between groups of private ATM switches. The PNNI supports the distribution of topology information between switches and clusters of switches to allow paths to be computed through the network. The PNNI also defines the signaling to establish point-to-point and point-to-multipoint connections across the ATM network. ATM Forum's Local Area Network Emulation supports the emulation of Ethernet, allowing ATM Networks to be deployed without disruption of host network protocols and applications. For information on the ASD (C3I) ATM guidance, see URL: <http://www.disa.mil> .
The standards below are mandated. For information on ATM-Forum-approved specifications, see URL: <http://www.atmforum.com/atmforum/specs/specs.html> .
ATM Forum, af-phy-0040.000 , Physical Interface Specification for 25.6 Mbps over Twisted Pair Cable, November 1995.
ATM Forum, af-phy-0015.000 , ATM Physical Medium Dependent Interface for 155 Mbps over Twisted Pair Cable, September 1994.
For User to Network Interface:
For Layer Management Capabilities:
For Traffic Management Functions:
For Circuit Emulation Functions:
For Private Network-to-Network Interfaces:
Gigabit Ethernet
While no specific LAN/CAN technology is mandated, when using Gigabit Ethernet (1,000 Mbps service) over fiber on a campus environment, the following physical layer and framing requirements standard is mandated:
IEEE 802.3-1998 , IEEE Standard for Information Technology (Clauses 34-42) - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (originally developed as IEEE 802.3z-1998).
When using Gigabit Ethernet over Category 5 copper cabling, the following standard is mandated:
IEEE 802.3ab-1999 , IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Physical Layer Parameters and Specifications for 1000Mb/s Operation over 4-Pair of Category 5 Balanced Copper Cabling, Type 1000BASE-T.
Transmission Media
Military Satellite Communications
Military Satellite Communications (MILSATCOM) systems include those systems owned or leased and operated by DoD and those commercial satellite communications (SATCOM) services used by DoD. The basic elements of satellite communications are a space segment, a control segment, and a terminal segment (air, ship, ground, etc.). An implementation of a typical satellite link will require the use of satellite terminals, a user communications extension, and military or commercial satellite resources.
Ultra High Frequency Satellite Terminal Standards
5-KHz and 25-KHz Service
For 5-KHz or 25-KHz single-channel access service supporting the transmission of either voice or data, the following standard is mandated:
5-KHz Demand-Assigned Multiple Access Service
For 5-KHz Demand-Assigned Multiple Access (DAMA) service, supporting the transmission of data at 75 to 2400 bps and digitized voice at 2400 bps, the following standard is mandated:
25-KHz Time Division Multiple Access/Demand-Assigned Multiple Access Service
For 25-KHz Time Division Multiple Access (TDMA)/DAMA service, supporting the transmission of voice at 2,400, 4,800, or 16,000 bps and data at rates of 75 to 16,000 bps, the following standard is mandated:
Data Control Waveform
For data controllers operating over single-access 5-KHz and 25-KHz UHF SATCOM channels, the following standard (a robust link protocol that can transfer error-free data efficiently and effectively over channels that have high error rates) is mandated:
Super High Frequency Satellite Terminal Standards
Earth Terminals
For minimum mandatory Radio Frequency (RF) and Intermediate Frequency (IF) requirements to ensure interoperability of SATCOM Earth terminals operating over C-, X-, and Ku-band channels, the following standard is mandated:
Extremely High Frequency Satellite Payload and Terminal Standards
Low Data Rate
For waveform, signal processing, and protocol requirements for acquisition, access control, and communications for Low Data Rate (LDR) (75 to 2,400 bps) Extremely High Frequency (EHF) satellite data links, the following standard is mandated:
Satellite State of Health Communication Standards
National Space Policy directed DoD to lead U.S. Government efforts to improve satellite operations interoperability among U.S. Government agencies. The National Security Space Architect's Satellite Operations Architecture Team recommended a common set of standards for low data rate satellite telemetry and commanding. These standards will allow DoD to share health and status resources with other U.S. Government agencies and with allies to enhance satellite operations while limiting costs. The standards provide a baseline for low data rate communication of health and status information between a spacecraft and the ground. These standards are mandated for S-band communication, but may be applied more generally.
For establishing the physical layer to support satellite health and status communications in the S-band during launch, early orbit, severe anomaly and disposal operations, the following standard is mandated:
For processing data being sent into distinct, easily distinguishable messages that allow reconstruction of the data with low error probability, the following standard is mandated:
For the data unit formats and functions implemented within the coding and physical layers of the satellite health and status communications, the following standard is mandated:
For procedures and data unit formats implemented within the segmentation and transfer layers of the telecommand data routing service, the following standard is mandated:
For detailed specification of the logic required to carry out command operation procedure-1 (COP-1) of the transfer layer, the following standard is mandated:
For the data unit formats and functions implemented within the application, system management, and packetization layers of the satellite command data management service, the following standard is mandated:
Packet telemetry provides a mechanism for implementing common data transport structures and protocols to enhance the development and operation of space mission systems. For facilitating the transmission of space-acquired data from source to user in a standardized manner, the following standard is mandated:
Radio Communications
Low Frequency and Very Low Frequency
For radio subsystem requirements operating in the Low Frequency (LF)/Very Low Frequency (VLF) frequency bands, the following standard is mandated:
High Frequency
High Frequency and Automatic Link Establishment
For both Automatic Link Establishment (ALE) and radio subsystem requirements operating in the High Frequency (HF) bands, the following standard is mandated:
Very High Frequency
For radio subsystem requirements operating in the Very High Frequency (VHF) frequency bands, the following standard is mandated:
Ultra High Frequency
Super High Frequency
For radio subsystem requirements operating in the Super High Frequency (SHF) frequency bands, the following standard is mandated:
Synchronous Optical Network Transmission Facilities
SONET is a telecommunications transmission standard for use over fiber-optic cable. SONET is the North American subset of the ITU standardized interfaces, and includes a hierarchical multiple structure, optical parameters, and service mapping. The following standards are mandated:
The citation of applicable ANSI standards for SONET does not ensure C4I interoperability in regions outside North America where standards for these services differ. The JTA recognizes that this is a critical area affecting interoperability but does not recommend specific solutions in this version.
Network and Systems Management
Network and Systems Management (NSM) provides the capability to manage designated networks, systems, and information services. This includes: controlling the network's topology; dynamically segmenting the network into multiple logical domains; maintaining network routing tables; monitoring the network load; and making routing adjustments to optimize throughput. NSM also provides the capability to review and publish addresses of network and system objects; monitor the status of objects; start, restart, reconfigure, or terminate network or system services; and detect loss of network or system objects in order to support automated fault recovery. A management system has four essential elements: management stations; management agents; management information bases (MIBs); and management protocols, to which these standards apply.
Data Communications Management
Data communications management stations and management agents (in end-systems and networked elements) shall support the Simple Network Management Protocol (SNMP). The following SNMP-related standard is mandated:
To standardize the management scope and view of end-systems and networks, the following standards are mandated for MIB modules of the management information base:
Telecommunications Management
Telecommunications management systems for telecommunications switches will implement the Telecommunications Management Network (TMN) framework. To perform information exchange within a telecommunications network, the following TMN framework standards are mandated:
ANSI T1.204 -1997 , OAM&P - Lower Layer Protocols for TMN Interfaces Between Operations Systems and Network Elements, 1997.
ANSI T1.208 -1997 , OAM&P - Upper Layer Protocols for TMN Interfaces Between Operations Systems and Network Elements, 1997.
ITU-T M.3211.1 , TMN management service: Fault and performance management of the ISDN access, 1996.
ISO/IEC 9595:1998 , Information Technology - Open Systems Interconnection Common Management Information Services (CMIS).
Emerging Standards
Commercial communications standards and products will evolve over time. The JTA must also evolve to benefit from these standards and products. The purpose of this section is to provide notice of those standards expected to be elevated to mandatory status when implementations of the standards mature.
End-System Standards
Internet Standards
IP Next Generation/Version 6 (IPv6). IPv6 is being designed to provide better internetworking capabilities than are currently available within IP (Version 4). IPv6 will include support for the following: expanded addressing and routing capabilities, authentication and privacy, auto-configuration, and increased quality of service capabilities. IPv6 is described by proposed and draft IETF standards including:
Lightweight Directory Access Protocol 3 (LDAPv3). The proposed standard for LDAPv3, IETF RFC 2251, supports standards-based authentication, referrals, and all protocol elements of LDAP (IETF RFC 1777). Other features still under development include standards-based access control, signed operations, replication, knowledge references, and paged results.
Mobile Host Protocol (MHP). This protocol allows the transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. A mobile IP protocol is currently available as an IETF-proposed standard, RFC 2002, entitled IP Mobility Support.
Quality of Service (QoS). QoS is the ability of a network to ensure that the predetermined traffic and service requirements of a network element (e.g., end-system, router, application) can be satisfied. Resource ReSerVation Protocol (RSVP) is used by a host to request specific qualities of service from the network for particular application data streams or flows. See See Network Quality of Service (QoS) Standards for emerging Network QoS standards. The following receiver-initiated QoS standard is emerging:
Voice Over IP (VoIP) . Voice Over IP technologies unite the telephony and data worlds, and allow voice traffic to be transmitted over corporate enterprise networks, intranets, and the Internet. Two nearly compatible approaches have been taken to bring voice to TCP/IP networks. On the one hand, the ITU has created H.323, a set of standards specifying protocols to encapsulate ISDN call signaling over an IP transport network. On the other hand, the IETF has created a set of standards to perform similar functions, under the names Session Initiation Protocol (SIP) and Media Gateway Control (Megaco). Both approaches use an IETF standard, RTP (Realtime Transport Protocol), for their voice channels. The SIP standard concerns simple call placement, but is designed so that its scope is easily expandable. Megaco neatly separates out the functions required for interoperability with legacy equipment such as Signaling System 7 circuit switches. In contrast, the H.323 standards for call placement, H.225, H.245, and Q.931 (including RAS) are explicit in the signals that may be sent and the expected responses. The following VoIP standards are emerging:
Video Teleconferencing Standards
There are three emerging standards for VTC over ATM:
ITU-T H.310 , includes underlying standards for video (MPEG2) and audio (MPEG1, MPEG2). H.310 can be used for high-quality VTC requiring > 2 Mbps infrastructure, but does not currently have much industry support.
ITU-T H.321 , specifies the operation of H.320 codecs over ATM using AAL-1 or AAL-5. H.321 uses Quality of Service to manage videoconferencing quality. It lacks industry wide support.
ITU-T H.323 , has the most industry support for VTC over ATM. It provides for two modes of operation over ATM: 1) IP over ATM media stream and 2) Real-Time Protocol (RTP) over ATM media stream transport (H.323 Annex C). Implementation of H.323 over non-LAN media (e.g., Metropolitan Area Networks [MANs] and WANs, such as the Internet, SIPRNET, JWICS) is still evolving.
Communication Protocols for High-Stress, Resource-Constrained Environments
DoD entered a cooperative effort in September 1997 with the National Aeronautics and Space Administration (NASA) and the National Security Agency (NSA) to develop Internet-based protocols for "stressed" communications links. Such links are characterized by one or more of: high bit error rates, long delays, low bandwidths, and high degrees of asymmetry. This work is also applicable for systems with limited computer processing power. The cognizant DoD office is SMC/XR. The protocol suite, called the Space Communications Protocol Specification (SCPS), increases the reliability and speed of data transfer over such links, increases interoperability with both DoD and non-DoD assets, and decreases the cost of operating our systems. This set of protocols is particularly applicable to radio frequency Internet communications in battlefield jamming environments. The suite has been issued as both Consultative Committee for Space Data Systems (CCSDS) and ISO standards (with the same content). The suite consists of the following four protocols that operate at and above the network layer of the Open Systems Interconnect (OSI) model:
The File Protocol (FP) is an application layer protocol (layer 7 in the OSI model) and is an extension of the Internet File Transfer Protocol (FTP). FP adds the ability to update individual records in a file, to suspend and resume file transfers at user request, to automatically restart file transmission in mid-transmission after a communications interruption, and to suppress the text of server replies. FP and FTP clients and servers can interoperate (at the reduced functionality of FTP, i.e., without the FP extensions).
The Transport Protocol (TP) is a transport layer protocol (layer 4 in the OSI model) and is an extension of the Internet Transmission Control Protocol (TCP). TP can provide better end-to-end throughput in a jamming or noisy radio frequency environment because it can respond to corruption and temporary link outage in addition to congestion. TP's selective negative acknowledgements increase performance in noisy and asymmetric environments. Performance in asymmetric environments is also improved by permitting reduced acknowledgement rates. TP also supports a loss-tolerant compressed TCP header and "best effort" data transfer protocol. TP and TCP clients and servers can interoperate (at the reduced functionality of TCP without the TP extensions).
The Security Protocol (SP) operates between the network and transport layers (layers 3 and 4). SP is an optional protocol that provides security capabilities (confidentiality, source authentication, and integrity) for the network layer. SP is analogous to IPSEC, but SP is a separate protocol with reduced overhead.
The Network Protocol (NP) is a network layer protocol (layer 3 in the OSI model) developed to be a bit-efficient, scalable protocol for a broad range of environments. Among other things, NP provides for selectable routing method, connectionless and managed-connection operations, corruption and congestion signaling to TP, and handling of packet precedence. NP is particularly useful in systems that have changing network connectivities. The other protocols can operate on Internet Protocol if Network Protocol is not used. In most cases IP packets and NP packets can be translated between each other using a gateway. The concept is that TCP/IP would be used in less stressed communication environments, and then translated or tunneled to NP where necessary before entering the stressed communications channel.
For stressed communications environments (such as satellite links) where high bit error rates, large delays, low bandwidth, and/or data rate asymmetry make the standard TCP/IP suite's performance unacceptable, the following standards are emerging for internetworking and file exchange:
CCSDS 713.0-B-1/ISO 15891:2000 , Space data and information transfer systems - Protocol specification for space communications - Network protocol, 5 October 2000. (Adopts MIL-STD-2045-4300)
CCSDS 713.5-B-1/ISO 15892 :2000, Space data and information transfer systems - Protocol specification for space communications - Security protocol, 5 October 2000. (Adopts MIL-STD-2045-4301)
More information is available at <http://www.scps.org> and <http://www.ccsds.org> .
Global Positioning System
The GPS Signal-in-Space (SIS) is being enhanced to accommodate next-generation security functions. These functions will significantly enhance the combatant commander's ability to use the GPS PPS capability and other GPS sensor information in all environments. These functions are exclusively supported by the Selective Availability Anti-Spoofing Module (SAASM) architecture. The following standard is being tracked as a GPS SIS emerging standard:
Network Standards
Wireless LAN
The 802.11 family of standards provide a common set of operational rules for airwave interoperability of wireless Local Area Network (LAN) products from different vendors. The original IEEE 802.11 standard was updated with editorial changes. The original physical layer was updated by IEEE 802.11a and IEEE 802.11b. The Medium Access Control (MAC) layer is currently undergoing revision and will be updated by IEEE 802.11f. The emerging standards include:
ISO/IEC 8802-11:1999 , (ISO/IEC) (IEEE Std 802.11 - 1999) Information Technology -Telecommunications and Information Exchange Between Systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
IEEE 802.11a-1999 , Supplement to Information technology - Telecommunications and Information Exchange Between Systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High Speed Physical Layer (PHY) in the 5 GHz Band.
IEEE 802.11b-1999 , Supplement to Information technology - Telecommunications and Information Exchange Between Systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Higher Speed Physical Layer (PHY) Extension in the 2.4 GHz band.
ATM-Related Standards
The following ATM-related standards are emerging:
ATM Forum, af-sig-0076.000 , Addendum to UNI Signalling V4.0 for ABR parameter negotiation, January 1997.
For ATM Conformance Testing, the ATM Forum's conformance test suites, Protocol Information Conformance Statement (PICS) pro forma and the Protocol Implementation Extra Information for Testing (Pixit) pro forma, are available to demonstrate interoperability between vendor products.
Network Quality of Service (QoS) Standards
Quality of Service is the ability of a network to ensure that the predetermined traffic and service requirements of a network element can be satisfied. Multiple forums including the IETF and IEEE are engaged in this evolving end-to-end networking effort to enhance the current networking architecture with support for QoS. To provide services over the LAN/WAN beyond the current best-effort IP-based service, the following standard protocols currently under development to enable end-to-end QoS, are emerging:
IETF RFC 2205 , Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification, September 1997.
ISO/IEC 15802-3 , IEEE 802.1D dtd 25 JUN 1998 Information Technology -Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks - Common Specifications - Part 3: Media Access Control (MAC) Bridges (Replaces IEEE P802.1P, 802.1J-1996, 802.6K-1992, 802.11C-1998, and P802.12E).
Personal Communications Services and Mobile Cellular
Personal Communications Services (PCS), second-generation mobile systems, will support both terminal mobility and personal mobility. Terminal mobility is based on wireless access to the public switched telephone network (PSTN). Personal mobility allows users of telecommunications services to gain access to these services from any convenient terminal (either wireline or wireless). Mobile cellular radio can be regarded as an early form of "personal communications service" allowing subscribers to place and receive telephone calls over the PSTN wherever cellular service is provided. The three predominant competing worldwide methods for digital PCS and Mobile Cellular access are: Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), and Global System for Mobile Communications (GSM). Of these three, CDMA offers the best technical advantages for military applications based on its utilization of Direct Sequence Spread Spectrum (DSSS) techniques for increased channel capacity, low probability of intercept (LPI), and protection against jamming. CDMA's low transmission power requirements should also reduce portable power consumption. It should be recognized that for Operations-Other-Than-War (OOTW), a user may require support of multiple protocols to access region-specific international digital PCS/Mobile Cellular infrastructures. The following PCS/CDMA standards and PCS/Mobile Cellular Interface standards are emerging:
ANSI/J-STD-018-96 , Recommended Minimum Performance Requirements for 1.8 to 2.0 GHz CDMA Personal Stations.
ANSI/J-STD-019-96 , Recommended Minimum Performance Requirements for Base Stations Supporting 1.8 to 2.0 GHz CDMA Personal Stations.
International Mobile Telecommunications - 2000
International Mobile Telecommunications - 2000 ( IMT-2000) defines third-generation mobile systems that were scheduled to start service around the year 2000. Also known as Future Public Land Mobile Telecommunications Systems (FPLMTS), these systems will provide access by means of one or more radio links to a wide variety of telecommunication services supported by the fixed and mobile telecommunications networks (e.g., PSTN/ISDN) and to other services that may be unique to IMT-2000. A range of mobile terminal types, designed for mobile and fixed use, is envisaged linking to terrestrial- and/or satellite-based networks. A goal for third-generation mobile systems is to provide global coverage and to enable terminals to be capable of seamless roaming between multiple networks. The ability to coexist and work with pre-IMT-2000 systems is required. The Radio Communications Assembly-2000 gave final approval of Recommendation ITU-R M.(IMT.RSPC), "Detailed Specifications of the Radio Interfaces of IMT-2000" for the radio interfaces for IMT-2000 on 5 May 2000. The IMT-2000 radio interface terrestrial standard consists of a set of radio interfaces, which allow performance optimization in a wide range of radio operating environments. The family of IMT-2000 terrestrial radio transmission technologies (RTT) is as follows: CDMA Direct Spread/CDMA Multi-Carrier/CDMA Time Division Duplex (TDD)/TDMA Single-Carrier/TDMA Multi Carrier. Follow-on work on major enhancements to the RTTs' specifications is ongoing in ITU-R Working Party 8F. In addition, standards work is continuing to ensure that the RTTs will support the capability of operating with the two worldwide telecommunications networks: evolved GSM-MAP and ANSI-41. Limited trials of 3G services are expected to be commenced in various regions of the world, especially Japan, in late 2001. The European Union plans a rollout of 3G services in 2002. U.S. 3G services (e.g., 144Kbps/384 Kbps data capability) are expected to be provided in focused markets in late 2003. A mass market for 3G in the U.S. and Europe is not expected to develop until 2005.
Military Satellite Communications
SHF Satellite Terminal Standards.
The following draft standards are under development: MIL-STD-188-166 (Interface Standard, Interoperability and Performance Standard for SHF SATCOM Link Control), MIL-STD-188-167 (Interface Standard, Message Format for SHF SATCOM Link Control), and MIL-STD-188-168 (Interface Standard, Interoperability and Performance Standards for SHF Satellite Communications Mulitplexers and Demultiplexers).
Radio Communications
Link 22 Transmission Standards
Link 22 Transmission media will be used to exchange Link 22 messages. Link 22 messages, composed of F-Series formats, will be used for the exchange of maritime operational data between tactical data systems using line of sight (UHF) and beyond line of sight (HF) bands. The standard for Link 22 waveform is under development.
Network Management
Simple Network Management Protocol Version 3 (SNMPv3)
The SNMPv3 Management Framework is described in IETF-Proposed Standard RFCs 2271-2275. SNMPv3 builds on the mandate SNMPV1 and addresses the deficiencies in SNMPv2 relating to security (e.g., authentication and privacy) and administration (e.g., naming of entities, usernames and key management, and proxy relationships). Implementations of the RFCs are undergoing interoperability tests as part of the process to advance these specifications from Proposed to Draft state.
Network Management Systems for Data Communications.
The following SNMP MIB modules are identified as emerging IETF standards for implementation within systems that manage data communications networks:
IETF RFC 1471 , Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1472 , Definitions of Managed Objects for the Security Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1473 , Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1474 , Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1657 ,Definitions of Management Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2, July 1994.
IETF RFC 2012 , SNMPv2 Management Information Base for the Transmission Control Protocol (TCP), November 1996.
IETF RFC 2013 , SNMPv2 Management Information Base for the User Datagram Protocol (UDP), November 1996.
Information Modeling, Metadata, and Information Exchange Standards
Introduction
Purpose
This section specifies the minimum information modeling, metadata, and information exchange standards DoD will use to develop or upgrade integrated, interoperable systems that directly or indirectly support the warfighter.
Scope
This section applies to activity models, data models, object models and data definitions used to define physical databases, and formatted messages used to exchange information among systems.
Security standards related to this section are in See Information Modeling, Metadata, and Information Exchange Security Standards.
Background
An information model is a representation at one or more levels of abstraction of a set of real-world activities, products, and/or interfaces. Within the Information System (IS) domain, there are three basic types of models frequently created: activity, data, and object.
Activity Models are representations of mission-area applications, composed of one or more related activities. The primary product of each activity model is the definition of a measurable set of products, services, and information required to support the mission-area function.
Data Models , developed from the information requirements documented in the activity model, define entities, their data elements, and illustrate the interrelationships among the entities. A data model identifies the logical information requirements and metadata, applicable to persistently stored data, which form a basis for physical database schemata and standard data elements within a relational database.
Object Models define the combined information and process requirements within a domain needed to accomplish a particular capability or set of capabilities, for example, as defined by activity models. Such models form the basis of object-oriented system implementations. They also model system interoperability by combining the metadata for shared data with the allowable interfaces for sharing that data. Such models show associations and dependencies between system interfaces and the essential business rules for exercising those relationships.
In order to provide an authoritative source for DoD data standards, DoD created the Defense Data Dictionary System (DDDS). The DDDS, managed by DISA, is a DoD-wide central database that includes standard names and definitions for data entities and data elements (i.e., attributes). The DDDS server also provides password-protected access to DoD standard data models. The DDDS is used to collect individual data standards derived from the DoD Data Model (DDM), now called the DoD Data Architecture (DDA), and to document content and format for data elements. System developers use this repository as a primary source of data element standards.
Information exchange is accomplished for the most part by sending formatted messages. The definition and documentation of these exchange mechanisms are provided by various messaging standards. Each message standard provides a means to define message form and functions (i.e., transfer syntax), which includes the definition of the message elements contained in each message. The message fields, which are currently defined in the various message standards, are not necessarily mutually consistent, nor are they consistently based on any activity or data models either within a message system or across message systems. Newer techniques provide more direct exchange of data without the user following a rigid format. A model-based structure will provide definitions that will be data element-based and will be compliant with DoD data element standards established in accordance with DoD Directive (DoDD) 8320.1, Data Administration, and associated DoD 8320.1 manuals.
Efficient execution of information exchange requirements (IERs) throughout the joint battlespace is key to evolving DoD toward the ultimate goal of seamless information exchange. The primary component of this infrastructure is the Tactical Data Link (TDL), composed of message elements/messages and physical media. However, due to the diversity of warfighter requirements, no single data link is applicable to every platform and weapon system.
Tactical Digital Information Links (TADILs), structured on bit-oriented message standards, evolved to meet critical real-time and near-real-time message requirements. The United States Message Text Format (USMTF), designed primarily for non-real-time exchange, is based on a character-oriented message format and is the standard for human-readable and machine-processable information exchange. The goal of TDLs, character-oriented/human-readable (USMTF messages), imagery, voice, and video standards is to provide a timely, integrated, and coherent picture for joint commanders and their operational forces.
Disparate data link message formats and communications media have resulted in late delivery of crucial battlefield information. This causes significant interoperability problems among the Commanders-in-Chief (CINCs), Services, Agencies (C/S/A), and allied nations. Currently, it is difficult to establish seamless information flow among diverse data-link units. Future joint operations, such as ballistic missile defense and battlefield digitization, will place greater emphasis on the need for automated C4I functions. Tomorrow's battlefields will vastly increase the burden on networks.
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for information modeling, metadata, and information exchange standards.
Activity Modeling
Activity models are used to document/model the activities, processes, and data flows supporting the requirements of process improvement and system development activities. Prior to system development or major system update, an activity model is prepared to depict the mission-area function to a level of detail sufficient to identify each entity in the data model that is involved in an activity. The activity model can form the basis for data and/or object model development or refinement. It is validated against the requirements and doctrine, and approved by the operational sponsor. IEEE 1320.1, IDEF0 Function Modeling, is the standard that describes the IDEF0 modeling language semantics and syntax, as well as associated rules and techniques, for developing structured graphical representations of a system or enterprise.
Data Modeling
Relational data models are used in software requirements analyses and design activities as a logical basis for physical data exchange and shared data structures that can benefit from a relational schema definition, including message formats and schema for shared databases. Object-oriented systems use data models to design relational data structures when there is a requirement to maintain persistent data storage for that system in a relational database. IDEF1X is used to produce a graphical information model, which represents the structure and semantics of information within an environment or system. FIPS PUB 184 is the standard that describes the IDEF1X modeling language (semantics and syntax) and associated rules and techniques for developing a logical model of data. Use of this standard permits the construction of semantic data models, which support the management of data as a resource, the integration of information systems, and the building of relational databases.
System engineering methodology internal to a system is unrestricted. The mandated standard for Data Modeling is:
DoD Data Model Implementation
The DoD Data Architecture (DDA) is an enterprise view of the data, which provides the standard definition of specific data elements to the developers of all DoD systems. The DDA has replaced the DoD Data Model (DDM) and is now available for use by the DoD Community. The DDA portrays DoD data standards grouped in functional views, which are aligned by Functional Data Administrators rather than subject areas as in the DDM. Tactical systems must incorporate applicable C2 Core Data Model (C2CDM) elements. The C2CDM is a subset of the DDA. Implementation of the DDA will be interpreted to mean that the DDA will serve as the logical reference model database schema defining the names, representations, and generalized relations of data within DoD systems. System developers comply by using this reference model database schema as a guide to reusable data structures that can form the basis of their own physical database schemas. Developers of new and existing systems will maintain traceability between data structures used in their physical database schemas and the DDA, by registering both the reuse of the data standards in the DDDS and the development/adoption of additional data structures. Information regarding access to the DDA can be obtained from the DoD Data Administration Web home page at <http://www-datadmn.itsi.disa.mil/> .
Adherence to the DDA for shared or sharable data will aid DoD Agencies in developing interoperability among all information systems. The shared or sharable data of a new or major system upgrade that are to be persistently stored in a relational or object-relational database will be documented within a data model based on the DDM. New information requirements for shared data are submitted by DoD Components and approved by functional data stewards in accordance with DoD Manual 8320.1-M-1, DoD Data Standardization Procedures. This data will be used to extend the DDA, as appropriate. System engineering methodology internal to a system is unrestricted. The following standard for DDA implementation is mandated:
DoD Data Definitions
The Defense Data Dictionary System (DDDS) is a central database that includes standard data entities, data elements, and provides access to DDM files from the DDDS server. The procedures for preparing and submitting data definitions and data models for standardization are covered in DoD Manual 8320.1-M-1. System developers shall use this repository as a primary source of data element standards.
Information Exchange Standards
Information Exchange Standards Applicability
Information Exchange Standards refer to the exchange of information among mission-area applications within the same system or among different systems. The scope of information exchange standards follows:
The exchange of information among applications using shared databases or formatted message structures shall be based on the logical data models developed from identifying information requirements through activity models, where appropriate. The data model identifies the logical information requirements, which shall be developed into physical database schemata and standard data elements.
The standard data elements shall be exchanged using the data-management, data interchange, and distributed-computing services of application platforms. (Refer to See Information Processing Standards for further guidance on these services.) The goal is to exchange information directly between information systems, subject to security classification considerations.
Information exchange between systems using object-oriented interface definitions can be based on object models depicting those interfaces and the functional dependency of those interfaces. With object models, standard data elements are typically associated with the atomic data attributes that represent shared data.
Information-Exchange standards help form the Defense Information Infrastructure (DII) Common Operating Environment (COE), ensuring the use of system or application formats that can share data. Key references include See Data Management Services, for SQL standards in Data Management Services and See Data Interchange Services for Data Interchange Services.
In distributed databases, other types of data messaging may be used as long as they remain DDDS-compliant.
Tactical Information Exchange Standards
The message standards below are joint/combined message standards that provide for the formatted transfer of information between systems. Although it must be recognized that the J-Series Family of TDLs and the USMTF Standards are not model-based and therefore do not meet the goals of standard information exchange, they must be recognized as existing standards. As more systems are developed using logical data models and standard data elements, these message standards must evolve to be data model-based if they are to continue to support joint automated systems. In distributed databases, other types of data messaging may be used as long as they remain DDDS-compliant.
Bit-Oriented Formatted Messages
The J-Series Family of TADILs allows information exchange using common data element structures and message formats that support time-critical information. They include Air Operations/Defense Maritime, Fire Support, and Maneuver Operations. These are the primary data links for exchange of bit-oriented information. The family consists of LINK 16, LINK 22, and the Joint Variable Message Format (VMF), and interoperability is achieved through use of J-Series family messages and data elements. The policy and management of this family are described in the Joint Tactical Data Link Management Plan (JTDLMP), dated 6 June 1996.
New message requirements shall use these messages and data elements or use the message construction hierarchy described in the JTDLMP. Where not addressed by another standard within the JTA (e.g., TADIL-J and VMF), the following standards are mandated as the format for transferring (though not processing) binary floating-point data:
Note: Between publications of the above mandated standards, the TADIL Interface Change Proposals (ICPs) status report lists changes to the standards. Once a TADIL ICP has the status "approved and awaiting incorporation," it is approved for implementation. The TADIL ICP Status Report is located at: <http://www-tadil.itsi.disa.mil/index.htm> .
Character-Based Formatted Messages
United States Message Text Format (USMTF) messages are jointly agreed, fixed-format, character-oriented messages that are human-readable and machine-processable. USMTFs are the mandatory standard for record messages when communicating with the Joint Staff, Combatant Commands, and Service Components. The mandated standard for USMTF Messages is:
Note: Per Service agreement, the USMTF is updated annually. Implementers have a full year from each release date to update their systems.
Binary Floating-Point Data Interchange
ANSI/IEEE 754-1985 defines formats and functional requirements for processing binary floating-point numbers including infinities and Not-a-Number values. A few standards with a larger scope define their own specialized binary floating-point format for use within the scope of that standard. Where not addressed by another standard within JTA (e.g., TADIL J and JVMF), the following standard is mandated as the format for transferring (though not processing) binary floating-point data:
Object Modeling
Object-oriented modeling techniques are used in the specification and development of object-oriented systems and to model and design the interoperability requirements of distributed components.
The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system. In an elaborative approach, developers develop models and increasingly add details until the model becomes the actual system being developed. Information may be obtained from the Web at http://www.omg.org . The following standard is mandated:
Emerging Standards
The emerging standards listed in this subsection are expected to be elevated to mandatory status when implementations of the standards mature.
Object Modeling
The XML Metadata Interchange (XMI) standard describes an information interchange model. This model allows developers using UML object technology tools to exchange programming data in a common format by defining a set of XML DTDs (Document Type Definitions) for exchanging UML information. The following standards are emerging:
DoD Data Definitions
The DISA Joint Information Engineering Organization (JIEO), in coordination with the Standards Coordinating Committee (SCC) and the Change Control Board (CCB), will develop the strategy/policy for migration from many tactical data-link (bit-oriented) and character-oriented joint message standards to a minimal family of DoD 8320.1-compliant information exchange standards. A normalized unified data/message element dictionary will be developed based on normalized Data Model and associated data element standards. The dictionary will support both character- and bit-oriented representation of the standard data and their domain values. Message standards will then establish the syntax for standard data packaging to support mission requirements (e.g., character- or bit-oriented, fixed or variable format, etc.). The unified data dictionary will ensure that multiple representations are minimized and transformation algorithms are standardized. The Data Model basis for the data elements will ensure that the information is normalized.
Information Exchange Standards
The emerging standards for information exchange are:
Multi-functional Information Distribution System (MIDS) , MIDS is a planned replacement for the Joint Tactical Information Distribution System (JTIDS). MIDS will provide secure jam-resistant communications, utilizing tactical digital data and voice. Message format standards for MIDS will not change from those of the JTIDS.
Data Modeling
IDEF1X97 is being developed by the IEEE IDEF1X Standards Working group of the IEEE 1320.2 Standards Committee. The standard describes two styles of the IDEF1X model. The key-style is used to produce information models that represent the structure and semantics of data within an enterprise and is backward-compatible with the U.S. Government's Federal Standard for IDEF1X, FIPS 184. The identity-style is a wholly new language that provides system designers and developers with a robust set of modeling capabilities covering all static and many dynamic aspects of the emerging object model. This identity-style can, with suitable automation support, be used to develop a model that is an executable prototype of the target object-oriented system. The identity-style can be used in conjunction with emerging dynamic modeling techniques to produce full object-oriented models. The following standard is emerging:
Human-Computer Interface Standards
Introduction
Purpose
This section provides a common framework for Human-Computer Interface (HCI) design and implementation in DoD automated systems. The objective is to standardize user interface design and implementation options thus enabling DoD applications within a given domain to appear and behave consistently. The standardization of HCI appearance and behavior within DoD will result in higher productivity; shorter training time; and reduced development, operation, and support costs.
Scope
This section addresses the presentation and dialogue of the Human-Computer Interface. See Information Processing Standards addresses the API definitions and protocols. See JTA See Human-Computer Interface Security Standards and Appendix A of the DoD HCI Style Guide, Security Presentation Guidelines, and other applicable portions of the DoD HCI Style Guide for HCI Security.
Background
The objective of system design is to ensure system reliability and effectiveness. To achieve this objective, the human must be able to effectively interact with the system. Humans interact with automated systems using the HCI. The HCI includes the appearance and behavior of the interface, physical interaction devices, graphical interaction objects, and other human-computer interaction methods. A good HCI is both easy to use and appropriate to the operational environment. It exhibits a combination of user-oriented characteristics such as intuitive operation, ease and retention of learning, facilitation of user task performance, and consistency with user expectations.
The need to learn the appearance and behavior of different HCIs used by different applications and systems increases both the training burden and the probability of operator error. What is required are interfaces that exhibit a consistent appearance and behavior both within and across applications and systems.
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for human-computer interfaces. Each mandated standard or practice is clearly identified on a separate bulleted line and includes a formal reference that can be included within Requests for Proposals (RFPs) or Statements of Work (SOWs).
General
The predominant types of HCIs include graphical user interfaces (GUIs) and character-based interfaces. Although GUIs are the preferred user interface, some specialized devices may require use of character-based interfaces due to operational, technical, or physical constraints. These specialized interfaces shall be defined by domain-level style guides and further detailed in system-level user interface specifications. In order to present a consistent interface to the user, application software shall not mix command line user interfaces and GUIs.
Graphical User Interface
When developing DoD automated systems, the graphical user interface shall be based on one commercial user interface style guide consistent with See Commercial Style Guides. Hybrid GUIs that mix user interface styles (e.g., Motif with Microsoft Windows) shall not be created. A hybrid GUI is composed of toolkit components from more than one user interface style. When selecting commercial off-the-shelf (COTS)/Government off-the-shelf (GOTS) applications for integration with developed DoD automated systems, maintaining consistency in the user interface style is highly recommended. An application delivers the user interface style that matches the host platform (i.e., Motif on a UNIX platform and Windows on an NT platform). This style conforms to commercial standards, with consistency in style implementation regardless of the development environment used to render the user interface. Applications that use platform-independent languages such as Java deliver the same style as the native application on the host platform.
See See User Interface Services for mandated GUI standards.
GUI Style Guides
An HCI style guide is a document that specifies design rules and guidelines for the look and behavior of the user interaction with a software application or a family of software applications. The goal of a style guide is to improve human performance and reduce training requirements by ensuring consistent and usable design of the HCI across software modules, applications, and systems. The style guide represents "what" user interfaces should do in terms of appearance and behavior and can be used to derive HCI design specifications defining "how" the rules are implemented in the application code.
See : HCI Development Guidance illustrates the hierarchy of style guides that shall be followed to maintain consistency and good HCI design within DoD. This hierarchy, when applied according to the process mandated in DoD's HCI Style Guide, provides a framework that supports iterative prototype-based HCI development. The process starts with top-level general guidance and uses prototyping activities to develop system-specific design rules.
The interface developer shall use the selected commercial GUI style guide and the appropriate domain-level style guide for specific style decisions, along with input of human factors specialists to create the system-specific HCI. The following paragraphs include specific guidance regarding the style guide hierarchy levels.
Commercial Style Guides
A commercial GUI style shall be selected as the basis for user interface development. The GUI style selected is usually driven by the mandates specified in See Information Processing Standards (User Interface Services and Operating System Services).
X-Window Style Guides
If an X-Windows-based environment is selected, the style guide corresponding to the selected version of Motif is mandated. The following Motif style guides are mandated:
M027 : CDE 2.1/Motif 2.1 - Style Guide and Glossary, The Open Group ISBN 1-85912-104-7, October 1997.
|
|
Domain-Level Style Guides
The JTA allows for the development of domain-level HCI style guides. These styles, when developed, will reflect the consensus on HCI appearance and behavior for a particular domain within DoD. The domain-level style guide will be the compliance document and may be supplemented by a system-level style guide. Domain-level style guides that make use of commercial standards, COTS products, graphical user interfaces, windows, and/or conventional displays should be developed as extensions to the User Interface Specification for the DII. Domain-level style guides should be complementary and nonconflicting with DoD HCI Interface and applicable commercial standards. The following domain-level style guide is mandated for HTML, Motif, and Windows-based systems:
System-Level Style Guides
System-level style guides provide the special tailoring of commercial, DoD, and domain-level style guides. These documents include explicit design guidance and rules for the system, while maintaining the appearance and behavior provided in the domain-level style guide. If needed, the Motif-based system-level style guide will be created in accordance with the User Interface Specification for the DII.
The process of developing effective system-level style guidance and specifications is dependent upon a proper process for human systems integration engineering, as shown in See : HCI Development Guidance. ISO 13407, "Human-centred design processes for interactive systems," provides a flexible model for inclusion of critical human systems integration issues into the design process. Use of this process leads to interactive systems that are easier to use, requires lower training and support costs, as well as improve user satisfaction and productivity. The process includes active involvement of users to achieve clear understanding of user/task requirements, appropriate allocations of function between users and technologies, and allows for iterative/multi-disciplinary design solutions to achieve the systems' interoperability and cost goals.
Emerging Standards
Symbology
The Geospatial Symbols for Digital Displays (GeoSym) specification defines the format and content of symbol graphics and symbol assignment tables. GeoSym symbols were created for use with VPF products and are designed to complement Common Warfighting Symbology (MIL-STD-2525B). For nonwarfighting, geospatial symbology, the following standard is emerging:
Currently, research is underway to investigate nontraditional user interfaces. Such interfaces may be gesture-based and may involve processing multiple input sources, such as voice and spatial monitors. Ongoing research and investigation includes the use of virtual reality and interface agents. Interface agents autonomously act on behalf of the user to perform various functions, thus allowing the user to focus on the control of the task domain. DoD will integrate standards for nontraditional user interfaces as research matures and commercial standards are developed.
Information Security Standards
Introduction
Purpose
This section provides the information security standards necessary to implement security at the required level of protection.
Scope
The standards mandated in this section apply to all DoD information technology systems. This section provides the security standards applicable to information processing, transfer, modeling, metadata, exchange, and Human-Computer Interfaces (HCI). This section also addresses standards for security audit and key management mechanisms. See Mandated Standards addresses mandated security standards, and See Emerging Standards addresses emerging security standards.
Background
Interoperability requires seamless information flow at all levels of information classification without compromising security. The goal is to protect information at multiple levels of security, recognizing that today's DoD systems are "islands" of system-high solutions.
The concept of security assurance provides confidence that the security features do what they are supposed to do, and that they do not do what they are not supposed to do. While assurance has been largely associated with product security, it is an equally important concept applied to system security since it is unlikely that integrated products will retain their individual assurance characteristics.
Systems that process sensitive data must be certified and accredited before use. Certification is the technical evaluation of security features and other safeguards, made in support of the accreditation. Accreditation is the authorization by the Designated Approving Authority (DAA) that an information system may be placed into operation. By authorizing a system to be placed into operation, the DAA is declaring that the system is operating under an "acceptable level of risk." Therefore, system developers should open dialog with the Certifier and DAA concurrently with their use of the Joint Technical Architecture (JTA), as DAA decisions can affect the applicability of standards within specific environments. The DoD Information Technology Security Certification and Accreditation Process (DITSCAP) is defined in DODI 5200.40.
DoD systems should have adequate safeguards to enforce DoD security policies and system security procedures. System safeguards should provide adequate protection from user attempts to circumvent system access control, accountability, or procedures for the purpose of performing unauthorized system operations.
Security requirements and engineering should be determined in the initial phases of design. The determination of security services to be used and the strength of the mechanisms providing the services are primary aspects of developing the specific security architectures to support specific domains. See Information Security Standards of the JTA is used after operational architectural decisions are made regarding the security services needed and the required strengths of protection of the mechanisms providing those services.
The proper selection of standards can also provide a basis for improved information protection. Although few specific standards for the general topic of "information protection" exist within Defensive Information Warfare, selecting standards with security-relevant content contributes to the overall improvement of the security posture of information systems.
For more information on implementing information systems and networks to provide defense-in-depth, see the Information Assurance Technical Framework (IATF), available at <http://www.iatf.net> .
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for information security standards. Each mandated standard or practice is clearly identified on a separate bulleted line and includes a formal reference that can be included within Requests for Proposals (RFPs) or Statements of Work (SOWs).
The Evaluation Criteria for Information Technology Security (Common Criteria) represents the outcome of efforts to develop criteria for evaluation of IT security that are widely useful within the international community. It is an alignment and development of a number of existing European, U.S., and Canadian criteria (ITSEC, TCSEC, and CTCPEC) respectively. The Common Criteria is a meta-standard (a standard of standards) as it is essentially a list of selectable security requirements (functional and assurance), plus definitions and requirements for how to document security capabilities and needs (as Security Targets and Protection Profiles respectively). The following standard is mandated for (1) defining common security requirements across multiple commercial or governmental implementations, by defining a Protection Profile (PP), and for (2) defining evaluation documentation demonstrating that a given system implements PP requirements through its Security Target (ST):
Introduction
This section contains the mandatory information security standards and protocols that shall be implemented in systems that have a need for the corresponding interoperability-related services. If a service is to be implemented, then it shall be implemented at the required level of protection using the associated security standards in this section. If a service is specified by more than one standard, the appropriate standard should be selected based on system requirements. See Mandated Standards is structured to mirror the overall organization of the JTA so that readers can easily link security topics with the related subject area in the sections of the JTA (information processing; information transfer; information modeling, metadata, and information exchange; and human-computer interface) and their sub-sections.
Information Processing Security Standards
Application Software Entity Security Standards
If FORTEZZA services are used, the following standards are mandated:
Application Platform Entity Security Standards
For the application platform entity, security standards are mandated for authentication services. Security is an important part of other application platform service areas, but there are no standards for the other service areas.
Authentication Security Standards
Authentication supports tracing security-relevant events to individual users. If Open Software Foundation DCE Version 1.1 is used, the following authentication standard is mandated:
If DCE Version 1.1 is not used, the following authentication standard is mandated:
Additional guidance documents: NCSC-TG-017 - A Guide to Understanding Identification and Authentication in Trusted Systems: NCSC-STD-002 DoD Password Management Guidance.
Information Transfer Security Standards
This section discusses the security standards that shall be used when implementing information transfer security services. Security standards are mandated for the following information transfer areas: end-system (host standards) and network (internetworking standards).
End-System Security Standards
Security standards for host end-systems are included in the following subsections.
Host Security Standards
Host end-system security standards include security algorithms, security protocols, and evaluation criteria. The first-generation FORTEZZA Cryptographic Card is designed to protect information in messaging and other applications.
For systems required to interface with Defense Message System for Organizational Messaging, the following standards are mandated:
Security Algorithms
To support interoperability using encrypted messages, products must share a common communication protocol. This protocol must include a common cryptographic message syntax, a common cryptographic algorithm, and a common mode of operation (e.g., cipher block chaining).
This section identifies security standards that shall be used for the indicated types of cryptographic algorithms: hashing, message digest, digital signatures, message encryption, and key exchange. If message digest or hash algorithms are required, Key Recovery will be implemented in a certificate management hierarchy. In FORTEZZA applications the following standards are mandated.
Note: Both the Key Exchange Algorithm (KEA) and the SKIPJACK Algorithm (FIPS-185) were declassified on 23 June 1998.
Security Protocols
The following standard is mandated for DoD systems required to exchange security attributes; for example, sensitivity labels:
Establishment of a certificate and key management infrastructure for digital signature is required for the successful implementation of the security architecture. This infrastructure is responsible for the proper creation, distribution, and revocation of end-users' public-key certificates. The following standard is mandated:
The Message Security Protocol (MSP) Version 4.0 has been revised to accommodate, in part, Allied requirements. All of MSP 4.0 features have been incorporated into Allied Communications Publication 120, Common Security Protocol. The following messaging security protocol is mandated for DoD message systems required to exchange sensitive but unclassified and classified organizational messaging:
The following standard is mandated for individual messages that use digital certificates issued by the DoD PKI to protect sensitive but unclassified individual messaging (e-mail):
Network Security Standards
Systems processing classified information must use Type 1 NSA-approved encryption products to provide both confidentiality and integrity security services within the network.
When network-layer security is required, the following security protocol is mandated:
The following standard is mandated for DoD systems required to exchange security attributes; for example, sensitivity labels:
Information Modeling, Metadata, and Information Exchange Security Standards
At this time, no information modeling, metadata, and information exchange standards are mandated. Process models and data models produced should be afforded the appropriate level of protection.
Human-Computer Interface Security Standards
At this time, no human-computer interface security standards are mandated.
Web Security Standards
The Secure Sockets Layer (SSL) protocol allows client/server applications to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. It is currently the de facto standard used by most browsers and popular e-mail packages that are associated with the browser. RFC 2246, The TLS Protocol, Version 1.0, January 1999, is an Internet Engineering Task Force (IETF) Proposed Standard and is expected to supersede SSL as a mandated standard within 2 years. Since Netscape is supporting TLS development, it is expected that there will be no further development of the SSL protocol by Netscape. The following standard is mandated:
Emerging Standards
The emerging standards listed in this subsection are expected to be elevated to mandatory status when implementations of the standards mature.
Introduction
The emerging security standards described in this section are drawn from work being pursued by ISO, IEEE, IETF, Federal standards bodies, and consortia such as the Object Management Group (OMG). See Emerging Standards is structured to mirror the overall organization of the JTA so that readers can easily link security topics with the related subject area in the sections of the JTA (information processing; information transfer; information modeling, metadata, and information exchange; and human-computer interface) and their subsections.
Information Processing Security Standards
Information processing security standards are emerging in applications software and application platform entity areas.
Application Software Entity Security Standards
Emerging application software entity standards include Web security standards.
Web Security Standards
RFC 2246, The Transport Layer Security (TLS) Protocol Version 1.0, January 1999, is an Internet Engineering Task Force (IETF)-Proposed Standard that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. It is based on the SSL 3.0 Protocol Specification as published by Netscape. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). TLS runs above the transport layer. TLS is expected to supersede SSL as a mandated standard within 2 years. Since Netscape is supporting TLS development, it is expected that there will be no further development of the SSL protocol by Netscape. The following standards are emerging:
Application Platform Entity Security Standards
For the application platform entity, security standards are emerging for software engineering, operating systems, and distributed computing services.
Software Engineering Services Security
For software engineering services, security standards are emerging for Generic Security Service (GSS)-Application Program Interface (API) and POSIX areas.
Generic Security Service-Application Program Interface Security
The Generic Security Service-Application Program Interface (GSS-API), as defined in RFC 1508, September 1993 (IETF), provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. RFC 1508 defines GSS-API services and primitives at a level independent of an underlying mechanism and programming language environment. RFC 2743, "GSS-API, Version 2.0," J. Linn, Update 1 January 2000, revises RFC 1508, making specific, incremental changes in response to implementation experience and liaison requests. The following standard is emerging:
The IETF, "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)," C. Adams, December 1998, extends the GSS-API (RFC 1508) for non-session protocols and applications requiring protection of a generic data unit (such as a file or message) independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. An example application is secure electronic mail in which data needs to be protected without any online connection with the intended recipient(s) of that data. Subsequent to being protected, the data unit can be transferred to the recipient(s)--or to an archive--perhaps to be processed as unprotected days or years later. The following standard is emerging:
Operating System Services Security
Operating system services security standards are emerging in the following areas: evaluation criteria and authentication.
Evaluation Criteria Security Standards
See See Mandated Standards for a description of the Common Criteria. More information on Common Criteria Protection Profiles is available on NIST's Web home page.
For the application platform entity, the following standards are considered emerging for the acquisition of operating systems consistent with the required level of trust:
Authentication Security Standards
IETF RFC 2289, "A One-Time Password System," February 1998, provides authentication for system access (login)--and other applications requiring authentication--that is secure against passive attacks based on replaying captured reusable passwords. The One-Time Password System evolved from the S/KEY One-Time Password System released by Bellcore. The following standard is emerging:
When Remote Dial-In Authentication is required, the following standard is emerging:
Distributed Computing Services Security Standards
Distributed Computing Environment (DCE) Authentication and Security Specification C311, August 1997, is a draft Open Group Specification for DCE.
The Common Object Request Broker Architecture (CORBA) Security Services define a software infrastructure that supports access control, authorization, authentication, auditing, delegation, non-repudiation, and security administration for distributed-object-based systems. This infrastructure can be based on existing security environments and can be used with existing permission mechanisms and login facilities. The key security functionality is confined to a trusted core that enforces the essential security policy elements. Since the CORBA Security Services are intended to be flexible, two levels of conformance may be provided. Level 1 provides support for a default system security policy covering access control and auditing. Level 1 is intended to support applications that do not have a default policy. Level 2 provides the capability for applications to control the security provided at object invocation and also for applications to control the administration of an application-specific security policy. Level 2 is intended to support multiple security policies and to provide the capability to select separate access control and audit policies. The following standards are emerging:
Information Transfer Security Standards
Security standards are emerging for the following information transfer areas: end-systems (host standards) and network (internetworking standards).
End-System Security Standards
Emerging end-system security standards include host standards discussed in the following subsection.
Host Security Standards
Emerging security standards for host end-systems in security protocols are discussed in the following subsection.
Security Protocols
In mid-1996, some significant improvements were proposed to the Secure/Multipurpose Internet Mail Extensions (S/MIME) messaging security protocol and the underlying encapsulation protocol, PKCS#7. With these improvements, S/MIME will provide a business-quality security protocol for both the Internet and X.400 messaging environments. The improvements include: (1) algorithm independence, (2) support for digitally signed receipts, (3) support for mail lists, and (4) support for sensitivity labels in signed and unsigned/encrypted messages. This effectively merges S/MIME and Message Security Protocol (MSP) 4.0/ACP-120. In November 1997, the IETF formed the S/MIME security protocol working group to create Internet standards based on S/MIME and these improvements. The following is an emerging standard:
It is expected that the Trusted Systems Interoperability Group (TSIG), Trusted Information for Exchange for Restricted Environments (TSIX (RE) 1.1) will adopt MIL-STD-2045-48501 as a replacement for its Common Internet Protocol Security Options (CIPSO) labeling standard.
The following IEEE-approved standard for Local Area Network (LAN) security and Metropolitan Area Network (MAN) security is emerging:
This IEEE standard provides specifications for security association management (Manual, Key Distribution Center, and Certification-based), security labeling and security services including data confidentiality, connectionless integrity, data origin authentication and access control. The Key Management Protocol (KMP) defined in Clause 3 is applicable to the Secure Data Exchange (SDE) protocol contained in the standards as well as other security protocols.
Medium-Assurance Public-Key Infrastructure Security Standards
Background
A public-key infrastructure (PKI) comprises the people, policies, procedures, and computing/telecommunications resources needed to manage public keys used by information systems. A PKI supports the following security services: authentication, data integrity, non-repudiation, confidentiality, and (optionally) authorization.
A PKI supports "X.509 public-key certificates," as defined in International Telecommunications Union-Telecommunications (ITU-T) Recommendation X.509. A public-key certificate is a data structure that binds a subject (people, applications programs, machines, etc.) and the subject's public key. A public-key certificate may contain additional attributes of the subject, such as address, phone number, and authorization (access control) data.
A PKI may support X.509 attribute certificates. An attribute certificate binds a subject and the subject's authorization data, such as group membership, roles, clearances, privileges, and restrictions. The authorization data does not guarantee access to information resources, as the decision to grant or deny access is made by the application that uses the certificate. Attribute certificates do not contain public keys.
A private key is used to digitally sign data, such as messages, files, and transactions. The corresponding public key is used to verify the signature. A private key can also be used to decrypt data encrypted with the corresponding public key. In the DOD medium-assurance PKI, the public/private-key pairs used for non-repudiation or digital signature services will be distinct from the pairs used for encryption/decryption services. Public/private-key pairs are also used in algorithms that automatically distribute symmetric, secret keys.
X.509 public-key certificates are signed and issued by a special user called a certification authority (CA). A CA may also revoke certificates. X.509 attribute certificates are signed, issued, and revoked by an attribute certificate issuer.
The DoD medium-assurance PKI is authorized to protect unclassified and certain types of sensitive but unclassified (SBU) information, in accordance with the DoD Class 3 level of information assurance. The DoD medium-assurance PKI may also be used for digital signature services, user authentication, and community of interest separation within certain types of classified networks protected by Type I cryptography. The U.S. DoD X.509 Certificate Policy specifies the permitted uses of a medium-assurance (Class 3) PKI in encrypted and unencrypted networks.
The standards listed below are the ones actually being used in the DoD medium-assurance pilot PKI. The standards are grouped according to the categories defined in the Internet Draft entitled "Internet X.509 Public Key Infrastructure PKIX Roadmap," <draft-ietf-pkix-roadmap-02.txt>, 23 June 1999, plus additional categories not mentioned in the Roadmap. Additional information on PKI policy can be found at <http://www-pki.itsi.disa.mil> .
Certificate Profiles
The DoD medium-assurance certificate profile implements the Federal PKI certificate profile, which in turn implements the Internet Engineering Task Force (IETF) profile, which in turn implements the ITU-T X.509 profile. Emerging certificate profile standards are:
Operational Protocols and Exchange Formats
Operational protocols deliver certificates and certificate revocation lists (CRLs) to certificate-using systems. The medium-assurance pilot uses RFC 2559, a profile of RFC 1777, Lightweight Directory Access Protocol, version 2, (LDAPv2), as its operational protocol. The following operational protocol is emerging:
Certificates and CRLs are stored in LDAP servers, which are accessed by certificate-using systems through LDAPv2. RFC 2587 specifies the minimal schema required to support certificates and CRLs in an LDAP server. An emerging standard for LDAP PKI servers is:
Certificates, private keys, and other personal data must be protected when they are moved between computers or removable media, such as smart cards or floppy disks. For secure or authenticated exchange of such personal data, the following standards are emerging:
Management Protocols
Management protocols support transactions involving management entities, such as CAs, Registration Authorities (RAs), and Local Registration Authorities (LRAs). Typical transactions are user registration, certificate enrollment, and certificate revocation. The following management protocols are emerging:
Although RFC 2315 and 2314 are based upon de facto standards from RSA Laboratories, Inc., the IETF is incorporating them into open, consensus-based standards, such as the Internet draft for "Certificate Management Messages over Cryptographic Message Syntax (CMC)." As the CMC draft matures, it will be considered for adoption as an emerging standard.
Application Program Interfaces (APIs)
API standards allow programmers to incorporate PKI services into their applications in a manner that supports applications portability. The following standard is emerging:
Cryptography
The following standards are emerging:
RSA Laboratories Public Key Cryptography Standard (PKCS) #1 , RSA Cryptography Standard, Version 2.0, 1 October 1998.
The following standard is emerging for PKI Class 3 implementations:
The following standard is emerging for encryption of sensitive but unclassified (SBU) data:
Network Security Standards
Emerging network standards are listed in See Internetworking Security Standards.
Internetworking Security Standards
IETF RFC 2401, "Security Architecture for the Internet Protocol," S. Kent and R. Atkinson, November 1998, describes the security mechanisms for IP and the services that they provide. Each security mechanism is specified in a separate document. RFC 2401 also describes key management requirements for systems implementing those security mechanisms. It is not an overall Security Architecture for the Internet, but focuses on IP-layer security.
This RFC specifies the base architecture for IPsec-compliant systems. It also describes the security services offered by the IPsec protocols and how these services can be employed in the IP environment. IPsec is designed to provide interoperable, high-quality, cryptographically based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper-layer protocols. These objectives are met through the use of two traffic security protocols: the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols.
The Internet Draft RFC 2402, "IP Authentication Header," S. Kent and R. Atkinson, November 1998, describes a mechanism for providing integrity and authentication for IP datagrams. An AH is normally inserted after an IP header and before the other information being authenticated. The AH is a mechanism for providing strong integrity and authentication for IP datagrams. It might also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed.
IETF RFC 2402 "IP Authentication Header," November 1998. The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams, and to provide protection against replays. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP), or in a nested fashion through the use of tunnel mode. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields.
IETF RFC 2406, "IP Encapsulating Security Payload (ESP)," November 1998, S. Kent and R. Atkinson, discusses a mechanism for providing integrity and confidentiality to IP datagrams. In some circumstances, depending on the encryption algorithm and mode used, it can also provide authentication to IP datagrams. Otherwise, the IP AH may be used in conjunction with ESP to provide authentication. The mechanism works with both IPv4 and IPv6. The ESP header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP AH [KA97b], or in a nested fashion, e.g., through the use of tunnel mode. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service.
IETF RFC 2104, "HMAC: Keyed-Hashing for Message Authentication," February 1997, H. Krawczyk (IBM), M. Bellare (UCSD), R. Canetti (IBM). This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function.
IETF RFC 1829, "The ESP DES-CBC Transform," P. Karn (Qualcomm), P. Metzger (Piermont), W. Simpson (Daydreamer), August 1995. The Encapsulating Security Payload (ESP) provides confidentiality for IP datagrams by encrypting the payload data to be protected. This specification describes the ESP use of the Cipher Block Chaining (CBC) mode of the U.S. Data Encryption Standard (DES) algorithm (FIPS PUB 46, FIPS PUB 46-1, FIPS PUB 74, FIPS PUB 81). All implementations that claim conformance or compliance with the ESP specification must implement this DES-CBC transform. RFC 2451, "The ESP CBC-Mode Cipher Algorithms," R. Periera and R.Adams, November 1998 and RFC 2405, "The ESP CBC-Mode Cipher Algorithm with Explicit IV," C. Madson and N. Doraswamy, November 1998, are examples of encryption algorithms used for ESP.
Draft FIPS 46-3 Data Encryption Standard (DES). For those systems required or desiring to use a cryptographic device to protect privacy act information and other unclassified, non-Warner Act exempt information, the Data Encryption Standard (DES) may apply. The DES is found in draft FIPS 46-3 Data Encryption Standard. IETF RFC 2420. The PPP Triple-DES Encryption Protocol (3DESE) is a complement to FIPS 46-3.
The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure, yet it has no strong security mechanisms to ensure data integrity or authentication. IETF RFC 2065, "DNS Security Extensions," D. Eastlake, C. Kaufman, January 1997, describes extensions to the DNS that provide these services to security-aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security-aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public-key distribution service as well as DNS security.
IETF RFC 2408,"Internet Security Association and Key Management Protocol (ISAKMP)," Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, 21 February 1998, describes a protocol utilizing security concepts necessary for establishing Security Associations (SAs) and cryptographic keys in an Internet environment. It is expected that the IETF will adopt this protocol as the Internet standard for key and security association management for IPv6 security.
The IETF Draft, "The Resolution of ISAKMP with Oakley," D. Harkins, D. Carrel (Cisco Systems), February 1997, describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec Domain of Interpretation (DOI). ISAKMP provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key-exchange-independent; that is, it is designed to support many different key exchanges. Oakley describes a series of key exchanges--called "modes"--and details the services provided by each (e.g., perfect forward secrecy for keys, identity protection, and authentication).
RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP," D. Piper, November 1998, details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. The ISAKMP defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given DOI. The following standards are emerging:
The following IEEE-approved standard for Local Area Network (LAN) security and Metropolitan Area Network is emerging:
RFC 2228, File Transfer Protocol, October 1997, defines extensions to the FTP standard (STD9/RFC 959). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels. RFC 2228 also introduces new optional commands, replies, and file transfer encodings. The following standard is emerging:
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The following standard is emerging for securing specific terminal and X-Windows sessions:
Firewall Standards
The following emerging standards will apply to Firewall devices in Basic Robustness environments:
The following emerging standards will apply to Firewall devices in Medium Robustness environments:
Human-Computer Interface Security Standards
Refer to See Medium-Assurance Public-Key Infrastructure Security Standards for information pertaining to Medium-Assurance Public-Key Infrastructure Security Standards.
C4ISR: Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance Domain
Domain Overview
Purpose
The C4ISR Domain identifies elements (i.e., standards, interfaces, and service areas) specific to the functional areas of command, control, communications, computers, intelligence, surveillance, and reconnaissance that are additions to those standards listed in the JTA Core. These additions are common to the majority of C4ISR systems and support the functional requirements of C4ISR systems.
Background
The scope and elements listed in JTA Version 1.0 focused on C4I. Version 2.0 expanded the scope to include the areas of C4ISR, Modeling and Simulation, Weapon Systems, and Combat Support. The sections describing these areas are referred to as domain annexes.
Domain Description
The C4ISR Domain consists of those integrated systems of doctrine, procedures, organizational structures, personnel, equipment, facilities, and communications whose primary focus is on one or more of the following functions:
Support properly designated commanders in the exercise of authority and direction over assigned and attached forces across the range of military operations.
Collect, process, integrate, analyze, evaluate, or interpret available information concerning foreign countries or areas.
This will specifically address the information technology (IT) aspect of the C4ISR Domain. It should be noted that this does not include those systems or other IT components specifically identified as belonging to the Combat Support Domain or whose primary function is the support of day-to-day administrative or support operations at fixed-base locations. Examples of such systems include acquisition, finance, human resources, legal, logistics, and medical systems, and items such as general-purpose LANs, computer hardware and software, telephone switches, transmission equipment, and outside cable plant. The position of the C4ISR Domain in the JTA Hierarchy Model is shown in See : JTA Hierarchy Model.
|
|
Scope And Applicability
The elements listed in this domain are mandated for use on all emerging systems or upgrades to existing systems developed to meet the functional area of C4ISR. Users of this document are encouraged to review other domain annexes to better gauge which domain is applicable.
Technical Reference Model
This domain uses the DoD Technical Reference Model cited in See DoD Technical Reference Model of the JTA as its framework. Additional service areas required to support the C4ISR Domain are addressed in See Domain-Specific Service Areas, Domain-Specific Service Areas.
Domain Organization
The C4ISR Domain consists of three sections. C4ISR.1 contains the overview, C4ISR.2 contains Information Technology standards that are additions to those contained in the JTA Core, and C4ISR.3 is reserved for those elements that are domain-specific because they do not map directly to the JTA Core service areas.
Additions to the JTA Core
Introduction
The following sections map to the service areas of the main body of the JTA. They identify standards, profiles, and practices that are applicable to the C4ISR Domain, but have not yet been selected for inclusion in the JTA Core.
Information Processing Standards
Introduction
The information processing standards and profiles described in this section promote seamless interoperability for C4ISR systems through the use of standardized interfaces for application platforms and software.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for information processing that shall be used in the development and acquisition of C4ISR systems. These are in addition to those listed in the Core, which are mandated for all systems that utilize information technology.
Still Imagery Data Interchange
The National Imagery Transmission Format Standard (NITFS) allows for Support Data Extensions (SDEs), which are a collection of data fields that provide space within the NITF file structure for adding functionality. Documented and controlled separately from the NITFS suite of standards, SDEs extend NITF functionality with minimal impact on the underlying standard document. SDEs may be incorporated into an NITF file while maintaining backward compatibility because the identifier and byte count mechanisms allow applications developed prior to the addition of newly defined data to skip over extension fields they are not designed to interpret.
Imagery Chip, Version B (ICHIPB) is a system-independent NITF SDE that, when included with NITF image chips, will support mensuration of non-dewarped imagery. This NITF SDE holds the support data analysts need when using imagery software to mensurate or determine detailed geospatial parameters on pixel-based features within image chips. There is no mechanism in the standard NITF format to pass a standardized set of data with an image chip such that a user can easily apply imagery software to that image. The following standard is mandated for NITF systems that use National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery:
The Profile for Imagery Access Extensions (PIAE) SDE is designed to provide an area to place fields not available in the NITF but which were documented in the canceled Standards Profile for Imagery Access (SPIA). The PIAE was developed to align the SPIA and NITF for product information and adds descriptive detail associated with products. The following standard is mandated for NITF systems that use imagery from National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery:
The Airborne SDE supersedes the VIMAS SDE and SAR SDEs described in version 1.0 of the NITFS Compendium of Controlled Extensions. The Airborne SDE incorporates all NITF tagged records relevant to SAR, Electro-Optical, Multispectral, and Hyperspectral primary imagery. Systems that use NITF imagery from airborne sensors shall be designed to extract data from the records described in this SDE. The following standard is mandated for NITF systems that exploit Tactical/Airborne imagery:
The History Tag, Version A (HISTOA) Softcopy History Tag, provides a history of any softcopy-processing actions applied to an NITF image. These extensions describe the format for support information within an NITF file containing National System Imagery. The following standard is mandated for NITF systems that exploit NTM:
Emerging Standards
The Air Group IV/SIAR Working Group under the NATO Air Force Armaments Group (NAFAG) has developed NATO Secondary Imagery Format (NSIF) STANAG 4545. The aim of this agreement is to achieve interoperability for transmission of Electronic Secondary Imagery among NATO C3I Systems. This STANAG was developed in cognizance with the International Organization for Standardization (ISO) Basic Imagery Interchange Format (BIIF) and the US MIL-STD-2500B on National Imagery Transmission Format (NITF). The following standard is emerging:
Common Ground Moving Target Indicator Data Format
The Common Ground Moving Target Indicator (CGMTI) Data Format is emerging as a de facto U.S./NATO data format for the dissemination of GMTI imagery from airborne and spaceborne GMTI sensor platforms. It is being developed as a product of the CGMTI Format Working Group, which was established to define and develop a standard that facilitates the transmission, processing, fusion, and display of GMTI data. Details of the Working Group are available at the CGMTI Web site, URL <http://www.rl.af.mil/programs/cgmti/> .The following document is identified as an emerging standard for systems that disseminate GMTI data:
Information Transfer Standards
Introduction
The information transfer standards and profiles described in this section promote seamless communications and information transfer interoperability for C4ISR systems through the use of standardized interfaces for end-systems, networks, transmission media, and systems management.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for information transfer that shall be used in the development and acquisition of C4ISR systems. These are in addition to those listed in the Core, which are mandated for all systems that utilize information technology.
Transmission Media
Transmission media refers to the physical paths used to transfer information among Components within the same system or among different systems.
Radio Communications
This section addresses standards that facilitate the interoperability of C4ISR systems that utilize the portion of the electromagnetic spectrum below 300 GHz for wireless communication.
Common Data Link Standards
The Common Data Link (CDL) is a flexible, multipurpose radio link-based digital communication technology developed by the Government for use in imagery and signals intelligence collection systems. It provides standard waveforms that follow a line-of-sight microwave path (link) and allows both full-duplex and simplex communications between airborne/space-based platforms and surface-based terminals. The CDL system supports air-to-land/sea surface, and air-to-satellite (relay/beyond line-of-sight) communications modes.
The term CDL refers to a family of interoperable data link implementations that offer alternate levels of capabilities for different applications/platforms. Five classes (Class I through Class V) of CDL have been defined. The Class I CDL standard addresses land/sea surface terminals that provide remote operation of airborne platforms operating up to 80,000 feet at mach 2.3 or less. The current land-based implementation of Class I CDL is the Miniature Interoperable Surface Terminal (MIST). The current sea-based implementation of Class I CDL is the Common High Bandwidth Data Link Surface Terminal (CHBDL-ST). Classes II through V cover the remainder of the defined CDL systems and are based on maximum altitude ceilings and sometimes platform mach number: Class II to 150,000 feet at mach 5 or less; Class III to 500,000 feet; Class IV to 750 nautical miles and is part of a satellite; lastly Class V that operates above 750 nautical miles and is part of a relay satellite. The majority of DoD CDL interoperability and standardization efforts have been focused on the Class I line-of-sight CDL system specification.
The Office of the Assistant Secretary of Defense for C3I (OASD[C3I]) designated CDL as the DoD standard in a policy memorandum (OASD/C3I Common Data Link Policy Memorandum, 13 December 1991). A similar policy memorandum was released to mandate the use of the Tactical CDL (OASD[C3I] Tactical Data Link Policy Memorandum, 18 October 1994). The following mandated standards apply for unified configuration control and standardized communications paths between airborne reconnaissance platforms that contain multiple sensors:
Unattended MASINT Sensor Communication Standards
Unattended Measurement and Signature Intelligence (MASINT) Sensors (UMSs) are small, autonomously powered, disposable systems that can be deployed by airborne platforms or ground personnel. UMS can contain one or more types of sensors (seismic, acoustic, IR, magnetic, chemical, or radiological) that transmit alarm messages or data when triggered by enemy activity. The SEIWG-005 standard specifies the frequencies, data formats, and protocols for this class of sensors in order to relay the data back via communication links and data relays, to a common exploitation station. The following standard is mandated for use in UMS systems:
Emerging Standards
The Program Management Office for Night Vision/Reconnaissance and Target Acquisition (PM NV/RSTA) has developed the Sensor Link Protocol (SLP) for use as a common local network interface between RSTA sensor systems and a host computer system. It is anticipated that SLP will evolve to provide a stable sensor interface baseline within the Intelligence and Electronic Warfare (I/EW) community. The following standard is emerging:
Information Modeling, Metadata and Information Exchange Standards
Introduction
The information modeling, metadata, and information exchange standards and profiles described in this section facilitate interoperability between C4ISR systems through the use of standardized activity models, data models, data definitions, and formatted messages.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for information modeling, metadata, and information exchange that shall be used in the development and acquisition of C4ISR systems. These are in addition to those listed in the, which are mandated for all systems that utilize information technology.
Information Exchange Standards
Information Exchange refers to the exchange of information among mission-area applications within the same system or among different systems.
Target/Threat Data Interchange Standards
The National Target/Threat Signature Data System (NTSDS) has been designated as a migration system, in accordance with guidance from ASD (C3I) and by the Intelligence Systems Board (ISB). NTSDS provides the DoD signature data community (e.g., ISR and MASINT) signature data from multiple, geographically distributed sites via a unified national system. NTSDS Data Centers employ standard data parameters and formats for stored target signatures for national and DoD customers. The following data standards are mandated for the DoD signature data community when interchanging national target/threat data:
Human-Computer Interface Standards
Introduction
The human-computer interface standards and profiles described in this section facilitate interoperability between C4ISR systems through the use of standardized user interfaces, style guides, and symbology.
Information Security Standards
Introduction
The information security standards and profiles described in this section facilitate interoperability between C4ISR systems through the use of standardized security interfaces for systems that process, transport, model, or exchange information.
Domain-Specific Service Areas
Introduction
The following sections map to service areas that apply to the C4ISR Domain, but not to the JTA Core. The standards, profiles, and practices identified are applicable only in the context of these service areas.
Payload-Platform Interface
Introduction
The interface standards identified in this section address interoperability requirements for the integration of a C4ISR payload (e.g., sensor package, communications relay) into a manned or unmanned aerospace platform. It is recognized that vehicle interface characteristics are often driven by the requirements of legacy technologies or other onboard systems. In these cases, the JTA rule set described in See Overview of the Department of Defense Joint Technical Architecture of the JTA Core, and as interpreted by individual Service/Agency JTA Implementation Plans, should be used to determine mandate applicability.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for the integration of a C4ISR payload into a manned or unmanned aerospace platform. It should be noted that the standards in this section apply to the platform only to the extent to which they directly affect the interoperability of onboard C4ISR systems.
At the present time, these mandates apply only to airborne reconnaissance systems.
Internal Communications
Internal communications provide information transfer capabilities between the platform and the onboard C4ISR systems, subsystems, and components. This section identifies the standards necessary to facilitate interoperability within and between these entities.
Fibre Channel
Fibre Channel is an efficient, high-speed, serial data communication technology for use in many environments including near-real-time high-speed data transfer, and local/campus networking environments. The Fibre Channel Physical and Signaling standards pertain to first three layers of the Fibre Channel stack (FC0, FC1, and FC2). FC0 addresses the physical media, FC1 discusses the data-encoding scheme, and FC2 addresses the framing protocol and flow control. The media chosen for Fibre Channel can accommodate speeds of 133, 266, and 531 Mbps and 1.06, 2.12, and 4.25 Gbps. The following standard is mandated for network communications internal to airborne reconnaissance platforms where Fibre Channel is used:
FireWire
FireWire describes a serial bus that provides the same services as modern IEEE-standard parallel buses. It has a 64-bit address space, control registers, and a read/write/lock operations set that conforms to IEEE Std 1212-1991, Command and Status Register (CSR). The following standard is mandated for serial bus communications internal to airborne reconnaissance platforms where FireWire is used:
Vehicle/Sensor Telemetry
Commands to various SIGINT, IMINT, and MASINT front-end equipment flow through airborne telemetry systems to onboard LANs. Sensor commands and acknowledgments may include position changes, mode changes, fault isolation commands, and others. The following telemetry standard is mandated for airborne reconnaissance systems:
Telemetry Group, Range Commanders Council, Telemetry Standards , IRIG 106-96, Secretariat, Range Commanders Council, U.S. Army White Sands Missile Range, New Mexico, Chapter 4, Pulse Coded Modulation Standards, Chapter 8 - MIL-STD-1553 Department of Defense Interface Standard for Digital Time Division Command/Response Multiplex Data Bus, 21 March 1996.
Mission Recorder
Mission recorders are used to capture the raw, pre-processed sensor data together with associated navigation, timing, and ancillary data. Additionally, a computer-controlled interface for basic recorder functions such as start, stop, shuttle, fast-forward, and rewind is included.
In conjunction with recording the raw sensor data, timing data will be recorded (on a separate track) in accordance with the standards defined below. The DCRSi 240 rack mount and modular ruggedized systems are one inch, transverse scan, rotary digital recorders capable of recording and reproducing at any user data rate from 0 to 30 Mbytes/s (0-240 Mbps). Specific compatibility information on the DCRSi 240 recorder can be found in the published AMPEX Digital Instrumentation Recorder DCRSi 240 User Manual. The ANSI digital recording standard, providing data compatibility and tape interchangeability, is provided by the X3.175 series. The Instrumentation Group IRIG-B standard was written specifically for analog magnetic tape storage. In conjunction with the migration to all digital systems, mission-recorder standards will be re-evaluated to emphasize digital and de-emphasize analog.
C4ISR.CRY: Cryptologic Subdomain
Subdomain Overview
The Cryptologic Subdomain supports the objectives that provide the framework for meeting the Cryptologic community's requirements.3 First, the Cryptologic Subdomain provides the foundation for interoperability and the seamless flow of information between and among all cryptologic systems and the associated service components in a collaborative and secure environment. Second, it establishes the minimum set of standards and technical guidelines for development and acquisition of new, upgraded, and demonstration systems necessary to achieve interoperability as well as reductions in costs and fielding times. Finally, it promotes interoperability with other components of the Intelligence Community (IC).
Purpose
The Cryptologic Subdomain mandates the minimum set of standards and guidelines for cryptologic systems and subsystems. This includes National and Tactical Cryptologic systems and subsystems. The provides the technical foundation for migrating United States Cryptologic System (USCS) systems toward a common Unified Cryptologic System architecture as directed by the Director, NSA (DIRNSA) and the Director, Central Intelligence (DCI).
Background
Faced with the challenges of keeping pace with changing intelligence requirements, budgetary uncertainty, and technological revolutions, the Director, National Security Agency, under the auspices of the Deputy Secretary of Defense and the Director, Central Intelligence, commissioned the Unified Cryptologic Architecture (UCA) study. The primary goal of the UCA study was to provide an architecture that would ensure an interoperable and secure USCS by 2010. The result of this study was the introduction of the UCA Operational, Systems, and Technical Architectures. The UCA Technical Architecture (UCA-TA) is complementary to the JTA and will be used in conjunction with the JTA Core and the JTA C4ISR Domain by all members of the Cryptologic community.
Subdomain Description
The Cryptologic Subdomain mandates standards for the Cryptologic community. The objective is to facilitate the exchange and exploitation of cryptologic data across the IC and the Department of Defense (DoD).
Scope
The scope of this includes the service areas of the JTA Core and C4ISR Domain, (Information Processing, Information Transfer, Information Modeling, Metadata and Information Exchange, human-computer Interface and Information Security Standards). This also addresses additional areas unique to the Cryptologic community including Special-Purpose Devices, backplanes, and circuit cards.
Applicability
This subdomain applies to all National and Tactical cryptologic systems, subsystems, and demonstration systems. It applies to all new acquisitions and upgrades to existing systems and subsystems that perform SIGINT and/or SIGINT-related activities. A cryptologic system is defined as any system within DoD that collects, processes, and/or manages SIGINT.
Subdomain Organization
The subdomain is divided into three sections. Section 1 contains the overview. This section defines the purpose and scope of the annex and provides background information. Section 2 contains standards for the Cryptologic community that are in addition to the standards in the JTA Core and the C4ISR domain service areas. Section 3 contains services and interfaces unique to the Cryptologic community.
Standards in Addition to the JTA Core and C4ISR Domain
Introduction
This part of the Cryptologic Subdomain establishes the minimum set of rules governing the information technology for cryptologic systems. The scope includes standards for information processing; information transfer; information modeling, metadata, and information exchange; information security; and human-computer interface.
Information Processing Standards
Information Transfer Standards
Information Modeling, Metadata, and Information Exchange Standards
Human-Computer Interface Standards
Subdomain-Specific Services and Interfaces
Introduction
Some cryptologic processing is performed using special-purpose devices (SPDs) that may be embedded within larger host systems or remotely located devices. Cryptologic systems encompass both real-time and non-real-time SPDs. The communications processing, signal processing, and mathematical analysis are performed in real-time by embedded systems that require speeds at least three orders of magnitude higher than traditional C4I systems. Real-time systems also require deterministic scheduling and robust fault tolerance.
Mandated Standards
Small-Scale Special-Purpose Devices
A Small-Scale Special-Purpose Device (SPD) consists of one or more special-purpose boards (may be Government-developed) hosted by a DII COE-compliant computer. These boards use Application Specific Integrated Circuits (ASICs) and Programmable Logic Devices (PLDs) typically designed and developed for the cryptologic community.
Cryptologic systems using PCI cards shall comply with the following mandated standard:
Cryptologic systems using PCMCIA cards shall comply with the following mandated standard:
Backplanes and Circuit Cards
To keep pace with a dynamic threat environment, Cryptologic systems often require the ability to quickly insert new technology. Standards for backplanes and circuit cards facilitate interoperability and modernization and can provide a "plug and play" capability.
Cryptologic systems using VME backplanes and circuit cards shall comply with the following mandated standard:
Cryptologic systems using VXI backplanes and circuit cards shall comply with the following mandated standard:
C4ISR.NCC: Nuclear Command and Control Subdomain
Subdomain Overview
Purpose
The Nuclear Command and Control (NCC) Subdomain identifies elements (i.e., standards, interfaces, and service areas) specific to the functional areas of nuclear command and control that are additions to those standards listed in the JTA Core and in the C4ISR Domain. These additions support the functional requirements of nuclear command and control (C 2 ) systems.
Background
This NCC Subdomain to the Joint Technical Architecture (JTA) has been developed to provide standards for programs being developed or maintained by USAF/AFMC/ESC/ND.
Subdomain Description
The NCC Subdomain to the JTA mandates the minimum set of standards and guidelines for nuclear C 2 systems.
Scope and Applicability
This part of the C4ISR Domain establishes the minimum set of rules governing information technology within nuclear command and control systems. The scope includes standards for information processing; information transfer; information modeling, metadata, and information exchange; human-computer interface; and information security.
The Nuclear Command and Control Subdomain constitutes only a part of the larger command and control part of C4ISR. As such, this subdomain does not cover technical architecture details for any part of the C4ISR spectrum other than the nuclear C 2 portion. Nuclear C 2 can use a variety of strategic and tactical C 2 systems, but the standards listed in this subdomain apply to these systems when used for nuclear C 2 missions. This annex covers nuclear C 2 from the JCS and nuclear CINC down to the last human in the loop prior to the nuclear weapon. The scope of this subdomain excludes the following:
The JTA mandates the minimum set of standards and guidelines for the acquisition of all DoD systems that produce, use, or exchange information. The main body of the JTA (the "Core") provides the standards that are applicable across the entire DoD information technology spectrum. If a service area in the Core applies to an NCC system being developed, and there is no corresponding service area in the C4ISR Domain, then the standard(s) listed in a Core service area apply. The mandates found in the C4ISR Domain are intended to augment those found in the Core. If additional service area standards are found in the C4ISR Domain, the developer must select the service area standards from both the Core and the C4ISR Domain. Similarly, the NCC Subdomain is intended to augment the C4ISR Domain. Applicable service area mandates found in the NCC Subdomain must be used in addition to the service area mandates found in the C4ISR Domain and the Core. When multiple mandates are required in this process, the mandate selection offering the best technical and business solution is the preferred decision.
The NCC Subdomain may list multiple standards for individual service areas. Similarly, the Core and the subdomain may offer multiple solutions within a single service area. For these cases, it is not required that the developer implement all standards listed. A subset should be selected based on technical merit and design/cost constraints. Future versions of this subdomain will have detailed information on standards implementation and standards profiles. The intent, as previously stated, is to promote a minimum set of standards for interoperability among NCC systems.
Technical Reference Model
This subdomain uses the DoD Technical Reference Model cited in See DoD Technical Reference Model of the JTA as its framework.
Subdomain Organization
The organization of this subdomain is intended to mirror the organization of the C4ISR Domain to the greatest extent possible. Each section of the subdomain, except for Part 1 (Overview), is divided into three subsections as follows. The first subsection, Introduction, is for information only. It defines the purpose and scope of the subsection and provides background descriptions and definitions unique to the section. The second subsection contains additional mandated standards for the identified service area. The third subsection, Emerging Standards, provides an abbreviated description of candidates that are expected to move into the mandated subsection within a short period. As defined within the JTA Core, this transition should occur within three years of publication of the standard in the emerging subsection.
C4ISR Application Platform Entity service areas are addressed in Section C4ISR.NCC.2 as additions to the JTA Core and C4ISR Domain. Additional application software entity service areas required to support NCC subdomain systems will be addressed in Section C4ISR.3, Domain-Specific Service Areas.
Additions to C4ISR Domain Service Areas
Introduction
This section provides standards available to this subdomain in addition to those listed in the JTA Core and C4ISR Domain.
Information Processing Standards
Information Transfer Standards
Introduction
Proper handling of NCC information is vital to national security. Information transfer standards and profiles described in this section cover dissemination and data link mandates for NCC systems. This section identifies systems and the interface standards required for interoperability between and among NCC systems and are in addition to the systems described in the JTA Core and the C4ISR Domain.
Mandated Standards
Additional mandated standards for information transfer for the NCC Subdomain are provided in this section.
For radio subsystems operating in the LF/VLF frequency bands, the following standards specify the special modes used by Air Force and Navy forces in support of the USSTRATCOM mission.
For sending and receiving High Data Rate (HIDAR)-mode communications the following standard is mandated:
For sending and receiving Minimum Essential Emergency Communications Network (MEECN) Message-Processing Mode (MMPM) communications the following standard is mandated:
Information Modeling, Metadata, and Information Exchange Standards
Introduction
This section identifies standards applicable to information modeling and exchange of information for NCC systems. Information Modeling, Metadata, and Information Exchange Standards pertain to activity models, data models, data definitions, and information exchange among NCC systems.
human-computer Interface Standards
Introduction
This subsection identifies the mandatory standards, profiles, and practices for human-computer interfaces within the NCC subdomain. The human-computer interface (HCI) is an extremely important NCC function.
Mandated Standards
This section will provide standards that uniquely apply to the HCI of NCC systems.
Information Security Standards
Introduction
Information security standards protect information and the processing platform resources. They must often be combined with security procedures, which are beyond the scope of the information technology service areas, to fully meet operational security requirements. Security services include security policy, accountability, assurance, user authentication, access control, data integrity and confidentiality, non-repudiation, and system availability control.
C4ISR.SR: Space Reconnaissance Subdomain
Subdomain Overview
Purpose
The Space Reconnaissance (SR) Subdomain (SRS) to the C4ISR Domain identifies the minimum set of technical supporting interfaces between SR information technology (IT) systems and other Department of Defense (DoD) systems. The IT definition used within the SRS is found in JTA See .The standards contained here are mandated for SR IT interfaces in addition to those standards found in the C4ISR Domain and in the JTA. The SRS will provide the foundation for the seamless flow of information and interoperability among all future and upgraded SR space and associated ground IT systems, IT technology concept demonstrations, and with related DoD IT systems. Standards used by SR legacy systems to support internal interfaces (i.e., interfaces to non-DoD systems) have not been examined and cannot be presumed to be JTA-compliant.
Background
Space Reconnaissance IT standards represent the communities engaged in all aspects of creating, deploying, and employing space reconnaissance assets for national defense. The standards within JTA (including the SRS) support a range of functions. The SRS supplies a special focus on space-related functions unique within JTA. The SRS identifies additional standards that have been determined to be unique to SR communications and data processing. Standards not unique to SR are contained in the C4ISR Domain or in the JTA Core. The location and application of standards within the JTA Core, C4ISR Domain and SRS are in accordance with the element normalization rules described in See Element Normalization Rules. Future versions of the SRS will address standards not previously identified, or not yet mature (under the JTA rule set), but expected to be developed into SRS-mandated standards. When identified, these standards will be placed in the emerging standards sections in each of the subdomain's service areas.
Subdomain Description
The SRS adds to the standards and guidance required for the Space Reconnaissance Subdomain and is meant to complement both the C4ISR Domain and the JTA Core. The SRS contains information on standards implementation and standards profiles.
The SRS will be maintained by the SRS Working Group chaired by the National Reconnaissance Office (NRO) with all changes made in concert with the normal JTA revision procedures. Modifications to the SRS will be coordinated with the established working group for the SRS.
Scope and Applicability
JTA compliance, where applicable, is required for acquisition of upgraded and new SR IT systems as well as advanced technology demonstrations. The SRS scope comprises SR IT system standards for interfaces external to DoD IT systems. The standards mandated in the JTA Core, C4ISR Domain, and SRS are applicable to the external SR IT interfaces. The SRS includes those pending SRS IT systems whose system specifications and design are intended for near-term acquisition and which include DoD interfaces, where appropriate. The SRS is also applicable where needed for the seamless flow of information and interoperability among SR systems with airborne and other intelligence, surveillance, and reconnaissance systems and is intended to complement their subdomains to the C4ISR Domain.
DoD Technical Reference Model
The DoD Technical Reference Model (TRM) is derived from the original Technical Architecture Framework for Information Management (TAFIM) reference model and Society of Automotive Engineers (SAE) Generic Open Architecture (GOA) model. GOA provides extensions to support real-time computing environments such as those found in weapon systems. The TRM is primarily a software-based model. It was originally developed to cover information technology within DoD. The TRM framework concept can be extended to cover SR external interface with DoD systems. However, domain-specific standards such as those required to cover all national space reconnaissance systems do not fully fit within this software-based model and so work continues as noted below.
SR TRM Defined
Various reference models are being evaluated for SR applicability. In the interim, the SRS uses the DoD Technical Reference Model (TRM) to cover SR system external interfaces with DoD IT systems. Where exceptions to the TRM are required, it will be noted in this subdomain. The DoD TRM is shown in See : DoD Technical Reference Model (DoD TRM) of the JTA.
Subdomain Organization
The organization of this Subdomain follows the JTA-approved format for developing domain and subdomains. The SRS contains three parts. C4ISR.SR.1 is the Overview. C4ISR.SR.2 includes mandatory standard profiles, practices, and emerging standards that are applicable to the SR Subdomain. Emerging standards provide an abbreviated description of candidates expected to move into the mandated subsection within a short period. As defined within the Core of the JTA, this transition should occur within three years of publication of the standard in the emerging subsection. C4ISR.SR.3 is reserved for those mandates that are subdomain-specific because they do not map directly to the JTA Core service areas.
Additions to C4ISR Domain Service Areas and JTA Core
Introduction
The SRS, in conjunction with the JTA Core and the C4ISR Domain, provides the technical foundation for migrating SR IT systems toward a technical architecture that provides interoperable interfaces to DoD systems. This section of the SRS lists the minimum, mandatory set of standards for SR systems. This section includes information processing; information transfer; information modeling, metadata, and information exchange; human-computer interface; and information security standards. This part of the SRS does not contain rules for the physical, mechanical, or electrical components of systems, even when these are related to information technology.
Information Processing Standards
Information Transfer Standards
Introduction
Information transfer standards are used to disseminate National and Tactical intelligence information to Joint service tactical units. This section identifies interface standards required for interoperability between SR IT and other DoD ISR systems in addition to the standards cited in the JTA Core and C4ISR Domain.
Information Modeling, Metadata, and Information Exchange Standards
Human-Computer Interface Standards
CS: Combat Support Domain
Domain Overview
Purpose
The Combat Support (CS) Domain has been developed to integrate agile combat support elements and other domains with a common technical architecture for information exchange. The goals for the Combat Support (CS) Domain are: 1) improve applications interoperability, promote improved business practices, and reduce operations costs within the Combat Support Domain, and 2) improve interoperability and increase combat support information access with C4ISR systems.
Background
There are numerous information technology services that support warfighter activities. These services need to be interoperable with the rest of the DoD community.
Domain Description
The Combat Support Domain addresses those specific elements necessary for the production, use, or exchange of information within and among systems supporting personnel, logistics, and other functions required to maintain operations or combat. The Combat Support domain consists of automated systems that perform combat service support and administrative business functions, such as acquisition, finance, human resources management, legal, logistics, transportation, and medical functions. As illustrated in See : JTA Hierarchy Model, the domain has three subdomains: Automatic Test Systems (CS.ATS), Defense Transportation System (CS.DTS), and Medical (CS.MED).
|
|
Scope and Applicability
The Combat Support Domain identifies standards applicable to DoD Combat Support Elements (e.g., Logistics, EDI, CALS, Medical, Transportation).
Technical Reference Model
This domain uses the Technical Reference Model (TRM) cited in See DoD Technical Reference Model of the JTA as its framework. Combat Support Application Platform Entity service areas are addressed in Section CS.2 as additions to the JTA Core. Additional Application Software Entity service areas required to support Combat Support Domain systems are addressed in Section CS.3 as domain-specific service areas.
Domain Organization
The Combat Support Domain consists of three sections. CS.1 contains the overview, CS.2 contains those information technology mandated and emerging standards that are additions to the standards contained in the Core, and CS.3 is reserved for those mandated and emerging standards for combat support that are domain-specific, not associated with a Core service area.
Additions to JTA Core
Introduction
The Combat Support Domain embraces the principles established in the JTA Core. Only those paragraphs from the Core that have additions are included below.
Information Processing Standards
Mandated Standards
Document Interchange
Continuous Acquisition and Life-Cycle Support (CALS) has developed a set of standards that apply to this service area. CALS Standard Generalized Markup Language (SGML) profiles the standard ISO 8879 by selecting a particular Document Type Definition (DTD) and other parameters that help standardize the development of technical manuals for DoD. CALS also developed a handbook for applying CALS SGML (MIL-HDBK-28001, 30 June 1995). Although Hypertext Markup Language (HTML) is also a subset of SGML, it is not sufficiently robust enough for Technical Manual (TM)/ Technical Order (TO) development. [Extensible Markup Language (XML) may replace both CALS SGML and HTML in the future.] CALS also has a standard for archiving documents (MIL-STD-1840C). The mandated standards for the CALS Document Interchange Service Area are:
Graphics Data Interchange
CALS has developed a metadata standard, MIL-PRF-28003B, which profiles the ISO Computer Graphics Metafile (CGM) standard (ISO 8632). Also, a CALS Raster Standard, MIL-PRF-28002C, puts raster graphics into a binary format. The mandated standards for the CALS Graphics Data Interchange service area are:
ISO/IEC 8632-1:1999 , Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 1: Functional specification, as profiled by MIL-PRF-28003B, Digital Representation for Communication of Illustration Data: CGM Application Profile, 30 April 2000.
ISO/IEC 8632-3:1999 , Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 3: Binary encoding, as profiled by MIL-PRF-28003B, Digital Representation for Communication of Illustration Data: CGM Application Profile, 30 April 2000.
ISO/IEC 8632-4:1999 , Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 4: Clear text encoding, as profiled by MIL-PRF-28003B, Digital Representation for Communication of Illustration Data: CGM Application Profile, 30 April 2000.
Product Data Interchange
Several standards exist for exchanging product data. The ANSI/US PRO/IPO-100-1996 and MIL-PRF-28000B standards define a neutral data format that allows the digital exchange of information between Computer-Aided Design (CAD) and Computer-Aided Manufacturing (CAD/CAM) systems. ANSI/US PRO-100-1996 supports digital design and manufacturing information about an object sufficient to support manufacturing and construction only. MIL-PRF-28000B contains applications subsets and protocols that form profiles of IGES Version 5.3. The following standard is mandated:
A standard for circuit board description in digital form is ANSI/IPC-D-350D. An associated standard for describing hardware product data in an unambiguous way is ANSI/IEEE 1076. Other product data can be stored digitally using MIL-STD-1840C. The following standards are mandated:
Bar code standards are used to identify packages and products. They can be used to help identify products being shipped and stocked. MIL-STD-1189B was canceled, but the notice directed the user to AIM BC-1, a linear bar code standard. (See See Product Data Interchange for two-dimensional standard.) The following standard is mandated:
Electronic Data Interchange
Electronic Data Interchange (EDI) is a new Base Service Area specializing in the computer-to-computer exchange of business information using a public standard. EDI is a central part of Electronic Commerce (EC), the paperless exchange of business information. FIPS PUB 161-2 establishes the Federal EDI Standards Management Coordinating Committee (FESMCC) to harmonize the development of EDI transaction sets and message standards among Federal agencies, and the adoption of Government-wide implementation conventions. The Federally approved Implementation Conventions may be viewed on the Web at <http://snad.ncsl.nist.gov/dartg/edi/fededi.html> .
The DoD EDI Standards Management Committee (EDISMC) was established to coordinate EDI standardization activities within DoD. The EDISMC supports the development, adoption, publication, and configuration management of EDI implementation conventions for DoD. The DoD EDISMC manages the efforts of several Functional Working Groups (FWGs). DoD FWGs have been established in the following areas: Logistics, Finance, Healthcare, Transportation, Procurement, and Communication, Command and Control. EDISMC-approved implementation conventions may be submitted to the FESMCC for approval as Federal implementation conventions. Not all DOD ICs are submitted to the FESMCC for federal approval. For more information, visit the web site at <http://www-edi.itsi.disa.mil> .
FIPS PUB 161-2, 22 May 1996, Electronic Data Interchange (EDI) adopts, with specific conditions, ANSI ASC X12, UN/EDIFACT and ANSI HL7. HL7 can be found in Combat Support Medical Subdomain. The following standards are mandated:
Emerging Standards
Product Data Interchange
ISO 10303, commonly called Standard for the Exchange of Product Model Data (STEP), is a standard for the computer-interpretable representation and exchange of product data. STEP provides a neutral mechanism capable of exchanging product data between different Computer-Aided Engineering (CAE), and Computer-Aided Design/Computer-Aided Manufacturing (CAD/CAM) applications. STEP supports the entire life cycle of a product, independent of any particular system, and supports 3D geometry, including 3D wireframe and 3D solid geometry. The following portions of STEP, ISO 10303, Industrial Automation Systems and Integration - Product Data Representation and Exchange, are emerging:
ISO 10303-1:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 1, Overview and fundamental principles.
ISO 10303-11:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 11:Description methods: The EXPRESS language reference manual.
ISO/TR 10303-12:1997 , Industrial automation systems and integration - Product data representation and exchange - Part 12: Description methods: The EXPRESS-I language reference manual.
ISO 10303-21:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 21: Implementation methods: Clear text encoding of the exchange structure.
ISO 10303-22:1998 , Industrial automation systems and integration - Product data representation and exchange - Part 22: Implementation methods:Standard data access interface.
ISO 10303-31:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 31: Conformance testing methodology and framework: General Concepts.
ISO 10303-32:1998 , Industrial automation systems and integration - Product data representation and exchange - Part 32: Conformance testing methodology and framework: Requirements on testing laboratories and clients.
ISO 10303-41:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 41: Integrated generic resources: Fundamentals of product description and support.
ISO 10303-42:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 42: Integrated generic resources: Geometric and topological represenation.
ISO 10303-43:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 43: Integrated generic resources: Representation structures.
ISO 10303-44:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 44: Integrated generic resources: Product structure configuration.
ISO 10303-45:1998 , Industrial automation systems and integration - Product data representation and exchange - Part 45: Integrated generic resources: Materials.
ISO 10303-46:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 46: Integrated generic resources: Visual presentation.
ISO 10303-47:1997 , Industrial automation systems and integration - Product data representation and exchange - Part 47: Integrated generic resources: Shape variation tolerances.
ISO 10303-49:1998 , Industrial automation systems and integration - Product data representation and exchange - Part 49: Integrated generic resources: Process structure and properties.
ISO 10303-101:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 101: Integrated application resources: Draughting.
ISO 10303-105:1996 , Industrial automation systems and integration - Product data representation and exchange - Part 105: Integrated application resources: Kinematics.
ISO 10303-201:1994 , Industrial automation systems and integration - Product data representation and exchange - Part 201: Application protocol:Explicit draughting.
ISO 10303-202:1996 , Industrial automation systems and integration - Product data representation and exchange - Part 202: Application protocol: Associative draughting.
Effective use of STEP to share product model data for systems requires a companion standard, ISO/IEC 13584, to exchange CAD Part Libraries (PLIB). The PLIB supplies a data model of the supplier part library, supplier identification, and part geometry. The following standard is emerging:
Information Transfer Standards
There are no mandated or emerging standards for the Combat Support Information Transfer Standards section.
Information Modeling, Metadata, and Information Exchange Standards
Electronic Fingerprint Information Exchange Standards
The electronic exchange of fingerprint information with automated fingerprint identification and analysis systems requires fingerprints to be electronically captured to image quality standards and to be formatted and documented in standard formats that are essential to interoperability. The following standard is mandated for the capture, fingerprint image compression/decompression, and exchange of electronic fingerprint information for the purpose of interoperating with criminal justice automated fingerprint information systems and repositories.
Domain-Specific Service Areas and Interfaces
Electronic Business/Electronic Commerce
Introduction
The Electronic Business/Electronic Commerce (EB/EC) Section provides standards useful for any DoD effort involved in electronic business operations. DoD focus on EB/EC has been limited primarily to acquisition-centric transactions. This limited scope has precluded DoD from taking full advantage of the significant process improvement and reengineering opportunity available through the implementation of EB/EC concepts and technology. EB/EC within DoD must now be thought of in a significantly larger perspective, which permits support of Finance, Procurement, Logistics, Personnel, Medical, Transportation, and Acquisition functions.
Mandated Standards
Smart Card Technology Standards
Smart Card standards are derived from identification-card standards and detail the physical, electrical, mechanical and application programming interface. ISO 7816 series is for contact Smart Cards while ISO 10536 specifies the standards for various types of contactless Smart Cards. Smart Card standards are essential for interoperability between multivendor cards and readers. The following ISO/IEC Series Standards for Smart Cards are mandated:
ISO/IEC 7816-1:1998 , Identification Cards - Integrated Circuit(s) cards with contacts - Part 1: Physical characteristics.
ISO/IEC 7816-2:1999 , Identification Cards - Integrated Circuit(s) cards with contacts - Part 2: Dimensions and location of the contacts.
ISO/IEC 7816-3:1997 , Identification Cards - Integrated Circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols.
ISO/IEC 7816-4:1995 , Identification Cards - Integrated Circuit(s) cards with contacts - Part 4: Interindustry commands for interchange.
ISO/IEC 7816-5:1994 , Identification Cards - Integrated Circuit(s) cards with contacts - Part 5: Numbering system and registration procedure for application identifiers.
ISO/IEC 7816-6:1996 , Identification Cards - Integrated Circuit(s) cards with contacts - Part 6: Interindustry Data Elements.
ISO/IEC 10536-1:1992 , Identification Cards - Contactless integrated circuit(s) card - Part 1: Physical characteristics.
Emerging Standards
Smart Card Technology Standards
The standards for both contact and contactless Smart Cards are still evolving and being specified. ISO 7816 series is for contact Smart Cards while ISO 10536, 14443, and 15693 specify the standards for various types of contactless smart cards. The following Smart Card standards are emerging:
ISO/IEC 7816-8:1998 , Identification Cards - Integrated circuit(s) card with contacts - Part 8, Security architecture and related interindustry commands.
ISO/IEC 7816-9:1999 , Identification Cards - Integrated circuit(s) card with contacts - Part 9: Enhanced interindustry commands.
ISO/IEC 7816-10:1998 , Identification Cards - Integrated circuit(s) card with contacts - Part 10: Electronic signals and answer to reset for synchronous cards.
ISO/IEC 10536-4:1995 Identification Cards - Contactless integrated circuit(s) card; Part 4, Answer to reset and transmission protocols.
ISO/IEC 14443-1:1998 , Identification Cards - Contactless integrated circuit(s) cards - Proximity integrated circuit(s) cards - Part 1: Physical characteristics.
ISO/IEC 14443-2:1999 , Identification Cards - Contactless integrated circuit(s) cards - Proximity integrated circuit(s) cards - Part 2: Radio Frequency Interface.
ISO/IEC 14443-3:1999 , Identification Cards - Contactless integrated circuit(s) cards - Proximity integrated circuit(s) cards - Part 3: Initialization and anti-collision.
ISO/IEC 14443-4:1999 , Identification Cards - Contactless integrated circuit(s) cards - Proximity integrated circuit(s) cards - Part 4 Transmission protocols.
ISO/IEC 15693-1:1999 , Identification Cards - Contactless integrated circuit(s) - Vicinity cards - Part 1: Physical characteristics.
ISO/IEC 15693-2:1999 , Identification Cards - Contactless integrated circuit(s) - Vicinity cards - Part 2: Air interface and initialization.
CS.ATS: Automatic Test Systems Subdomain
Subdomain Overview
Purpose
The Automatic Test Systems (ATS) Subdomain identifies additions to the Combat Support Domain Core elements (i.e., standards, interfaces, and service areas) listed in JTA Core of this document. These additions are common to the majority of ATSs and support the functional requirements of these systems.
The purpose of the ATS Subdomain is to:
Provide the foundation for a seamless flow of information and interoperability among all Department of Defense (DoD) ATS.
Mandate standards and guidelines for system development and acquisition that will significantly reduce cost, development time, and fielding time for improved systems, while minimizing the impact on program performance wherever possible.
Background
From 1980 to 1992, DoD's investment in depot and factory ATSs exceeded $35 billion with an additional $15 billion for associated support. Often, application-specific test capability was procured by weapon systems acquisition offices with little coordination among DoD offices. This resulted in a proliferation of different custom equipment types with unique interfaces that made DoD appear to be a variety of separate customers. To address this problem, DoD enacted policy changes requiring that "Automatic Test System capabilities be defined through critical hardware and software elements." In response, the joint service Automatic Test Systems (ATS) Research and Development (R&D) Integrated Product Team (IPT), known as ARI, has worked toward the definition of an ATS architecture based on open system principles. A summary of the ARI's work is presented in this subdomain . The ATS Subdomain will aid in satisfying the requirements of DoD Regulation 5000.2-R to migrate DoD-designated tester families toward a common architecture.
The policy changes listed below require DoD offices to take a unified corporate approach to acquisition of ATSs.
DoD Regulation 5000.2-R, Mandatory Procedures for Major Defense Acquisition Programs and Major Automated Information System Acquisition Programs, paragraph 4.3.3.4, March 15, 1996, brings a cost-effective approach to the acquisition of ATS. This policy requires hardware and software needs for depot- and intermediate-level applications to be met using DoD-designated families and commercial equipment with defined interfaces and requires the management of ATS as a separate commodity through a DoD Executive Agent Office (EAO). The policy also requires that the introduction of unique types of ATS into DoD field, depot, and manufacturing operations be minimized. Change 3 of DoD 5000.2-R, dated March 23, 1998, requires that the ATS selection "shall be based on a cost and benefit analysis that ensures that the ATS chosen is the most beneficial to the DoD over the system life cycle."
The use of open standards in ATSs has been projected to provide the following five benefits.4
Subdomain Description
An ATS has three major components: Automated Test Equipment (ATE), TPSs, and the Test Environment. The ATE consists of test and measurement instruments, a host computer, switching, communication buses, a receiver, and system software. The host computer controls the test and measurement equipment and execution of the TPS. The system software controls the test station and allows TPSs to be developed and executed. Examples of system software include operating systems, compilers, and test executives. The TPS consists of software to diagnose Units Under Test (UUT), a hardware fixture that connects the UUT to the ATE, and documentation that instructs the station operator on how to load and execute the TPS. The Test Environment includes a description of the ATS Architecture, programming and test specification languages, compilers, development tools, a standard format for describing UUT design requirements, and test strategy information that allows TPS software to be produced at a lower cost.
A high-level overview of a typical ATS is shown in See : Generic ATS Architecture. This architecture is expanded into more detail in the hardware and software technical reference models introduced in Section See Technical Reference Model. The interfaces in the technical reference models are discussed in more detail in See Additions to the JTA Core and See Subdomain-Specific Service Areas.
|
|
Scope and Applicability
The following factors guided the selection of interfaces in the ATS Subdomain.
Hardware and Software - Hardware and software associated with the supported test domains and software interfaces required to build ATS were included.
The standards selected for inclusion in the ATS Subdomain were found to be key for the generic, open system architecture of ATSs. The standards are based on commercial, open system technology, have implementations available, and are strongly supported in the commercial marketplace. Standards in the ATS Subdomain meet the following criteria:
Standards that are commercially supported in the marketplace with validated implementations available in multiple vendors' mainstream commercial products took precedence over other standards. Publicly held standards were generally preferred. International or national industry standards were preferred over military or other Government standards. Many standards have optional parts or parameters that can affect interoperability. In some cases, a standard may be further defined by a standards profile, which requires certain options to be present to ensure proper operation and interoperability.
Previously, each of the Services had established its own sets of standards (e.g., technical architectures). The ATS Subdomain is envisioned as a single, generic, open system architecture in DoD ATS. The ATS Subdomain shall be used by anyone involved in the management, development, or acquisition of new or improved ATSs within DoD. System developers shall use the ATS Subdomain to ensure that new and upgraded ATSs, and the interfaces to such systems, meet interoperability requirements. System integrators shall use this document to facilitate the integration of existing and new systems. Operational requirements developers shall be cognizant of the ATS Subdomain in developing requirements and functional descriptions. ATS is a subdomain of the Combat Support Domain of the JTA.
Technical Reference Model
Hardware
The hardware interfaces in a typical ATS are shown in See : Hardware Interfaces. Interfaces are only mandated if they affect the interoperability or life-cycle costs of DoD ATS, and are supported by widely accepted commercial standards. Interfaces are not mandated if they are not supported by commercial standards or do not affect the interoperability or life-cycle costs of DoD ATS. Interfaces that are not supported by commercial standards are included as emerging standards if they affect the interoperability or life-cycle costs of DoD ATS.
|
|
The interfaces shown in See : Hardware Interfaces are listed alphabetically by mnemonic below:
Computer Asset Controller Interface (CAC) describes the communication paths between the host computer and instrument controllers in a distributed system.
Computer to External Environments (CXE) describes the communication methods between a host ATS and remote systems.
Host Computer Interface (HST) describes the processing architecture of the primary control computer in which the TPS is executed and through which the operator interfaces.
Instrument Control Bus (ICB) interface describes the connection between the host computer or instrument controller and the test and measurement instruments in the ATS.
Software
The software interfaces are introduced using two reference models: a runtime view and a TPS development view. The interfaces applicable to the runtime view are shown in See : Test Program Sets Runtime Interfaces. These interfaces describe information processing flows as the TPS diagnoses a UUT. The TPS development interfaces are shown in See : Test Product Sets Development Interfaces.
|
|
|
|
In these diagrams, Host Computer refers to computers that run the ATS and instrument asset controllers and computers that are subordinate to the host. The runtime diagram presents a generic template for the functional organization of software processes. Subsets of this structure will appear on individual processors in a distributed-processing architecture. On any processor, if components shown on this diagram are present and interact, their interactions must comply with the interface requirements identified in this document.
The interfaces depicted in the runtime view of See : Test Program Sets Runtime Interfaces are listed alphabetically by mnemonic below:
Diagnostic Processing (DIA) is the interface protocol linking execution of a test with software diagnostic processes that analyze the significance of the test results and suggest conclusions or additional actions required.
Instrument Driver API (DRV) is the API through which instrument drivers accept commands from, and return results to, Generic Instrument Classes.
Framework (FRM) is a collection of system requirements, software protocols, and business rules (e.g., software installation) affecting the operation of test software with its host computer and operating system (OS).
Instrument Command Language (ICL) is the language in which instrument commands and results are expressed as they enter or leave the instrument.
Instrument Communication Manager (ICM) is the interface between the instrument drivers and the Communication Manager that supports communication with instruments independent of the bus or other protocol used (e.g., VXI, IEEE-488.2, RS-232).
Multimedia Formats (MMF) denotes the formats used to convey text, audio, video, and three-dimensional physical model information from multimedia authoring tools to the Application Development Environment (ADE), Application Execution Environment, and host framework.
Network Protocol (NET) is the protocol used to communicate with external environments, possibly over a Local or Wide Area Network. The software protocol used on the CXE hardware interface is represented by the NET software interface.
Resource Adapter Interface (RAI) is the interface through which instrument drivers accept commands from, and return results to, test procedures or runtime services serving the Test Program.
The interfaces depicted in the development view of See : Test Product Sets Development Interfaces are listed alphabetically by mnemonic below:
Application Development Environments (ADE) is the interface by which the test engineer creates and maintains a TPS, whether captured in the form of a text or graphical language.
Adapter Function and Parametric Data (AFP) is the information and formats used to define to the ADE the capabilities of the test fixture, how the capabilities are accessed, and the associated performance parameters.
Instrument Function and Parametric Data (IFP) is the information and formats used to define to the ADE the load, sense, and drive capabilities of the instruments; how these capabilities are accessed; and the associated performance parameters.
Switch Function and Parametric Data (SFP) is the information and formats used to define to the ADE the interconnect capabilities of the switch matrix, how these capabilities are accessed, and associated performance parameters.
Subdomain Organization
The ATS Subdomain consists of three main sections. See : Generic ATS Architecture contains the overview, See : Hardware Interfaces contains the additions to the JTA Core service areas for ATS, and See : Test Program Sets Runtime Interfaces contains the domain-specific service areas for ATS. A list of sources is provided in See . In cases where the ATS Subdomain does not address an interface to be used in an ATS, the JTA takes precedence. In cases where the JTA and ATS Subdomain specify different standards for the same interface, the ATS Subdomain takes precedence.
Additions to the JTA Core
Introduction
The standards in the ATS Subdomain apply in addition to the standards in the Combat Support Domain and the JTA Core.
Information Processing Standards
Mandated Standards
Data Interchange Services
Instrument Driver API Standards
The DRV is the interface between the generic instrument class serving the test procedure and the instrument driver. The calls made available at this interface include calls oriented to software housekeeping, such as initializing the driver itself; and calls that cause the instrument to perform a function, such as arm and measure commands. The service requests crossing this interface are communications between generic ATS assets (e.g., digital multimeter) and specific ATS assets (e.g., vendor XYZ model 123 digital multimeter). The instruments are ATS assets, but the calls to the driver are either direct or close-to-direct consequences of action requests in the Test Procedure, which is a TPS asset. Some instrument functions are available from a variety of instruments. However, the driver calls to access these functions vary from instrument to instrument. This interferes with TPS portability. Historically, cross-platform incompatibilities--in the way drivers for the same instrument implement the same function--have been a recurring ATS integration problem. In common commercial practice, the driver is acquired with the instrument from the instrument's original equipment manufacturer. The DRV API interface allows software developed by different organizations to work together. The following standard is mandated in this version of the JTA.
Digital Test Data Formats
Digital Test Data Formats (DTFs) describe the sequence of logic levels necessary to test a digital UUT. Digital test data is generally divided into four parts: patterns, timing, levels, and circuit models and component models used for the fault dictionary. In addition, certain diagnostic data may exist that is closely associated with the digital test data. This interface is intended to be used for capturing the output of digital automatic test pattern generators. A standard for describing DTF, known as LSRTAP, has become a de facto industry standard. The following standard is mandated in this version of the JTA:
Emerging Standards
Data Interchange Services
Resource Adapter Interface
The Resource Adapter Interface (RAI) provides a generic method for obtaining instrumentation services. These services isolate TPSs from test instruments by allowing test requirements to be described in TPSs rather than instrument-specific functions or commands that would tie TPSs to specific instruments. The RAI makes it easier to interchange instruments and instrument drivers, and allows virtual instruments to be developed. DoD is working with industry consortiums such as the VXI plug&play Systems Alliance and the Interchangeable Virtual Instruments Foundation to develop a common solution.
The following standards are emerging:
VPP-3.1 , VXI plug&play Systems Alliance: Instrument Drivers Architecture and Design Specification Revision 4.1 December 4, 1998.
VPP-3.2 , VXI plug&play Systems Alliance: Instrument Driver Functional Body Specification Revision 5.0 December 4, 1998.
Interchangeable Virtual Instruments (IVI) Foundation Standards:
Diagnostic Processing Standards
The diagnostic processing interface resides between the test procedure or runtime services supporting the TPS and a diagnostic reasoner, diagnostic controller, or other diagnostic process. Diagnostic tools are most frequently encountered in one of three forms: expert systems, decision-tree systems, and model-based reasoners. Other diagnostic tools are expert systems known as the Fault Isolation System and the Expert Missile Maintenance Advisor; decision-tree systems including Weapon System Testability Analyzer, System Testability and Maintenance Program, System Testability Analysis Tool, and AUTOTEST; and model-based reasoners including Intelligent-Computer-Aided Test, Portable Interactive Troubleshooter, Artificial-Intelligence Test, and Adaptive Diagnostic System.
Standardization in this area would allow tools to be written that can translate test strategy information to various test programming languages. Additionally, the tools would be interchangeable since one could use any tool to obtain the same output source code.
UUT Test Requirements Data Standards
High re-host costs in the past have been associated with the failure to record or preserve the signal-oriented action capabilities as required as opposed to as used. This problem is most visible in the allocation phase of TPS development. When a TPS is transported or re-hosted, the resources requested by the TPS must be allocated to assets in the target ATS. This task would be simplified if UUT test requirements were available in the form of load specifications, measurement requirements, and stimuli requirements that must appear at the UUT interface.The following standard is emerging:
Information Transfer Standards
Mandated Standards
Instrument Communication Manager Standards
The ICM interface includes bus-specific options for communicating from the instrument driver to a supporting input/output (I/O) library. Until recently, vendors of IEEE-488 and VXI bus hardware provided software drivers for their buses that were different according to the hardware bus protocol or operating system (OS) used. This situation interfered with the plug-and-play capabilities that users thought they were going to get from buying different instruments that all communicated by common hardware protocols. The same functions of the same instruments were not accessed through software in the same way across buses and host platforms. Different manufacturers of IEEE-488 cards had proprietary and unique software calls. Furthermore, Hewlett-Packard and National Instruments--the two leading vendors of VXI Slot 0 cards and embedded controllers--used different I/O calls to access instruments. This impeded the transporting of instrument drivers, ADEs, and test programs from one set of hardware to another. Without a standard ICM interface, vendors cannot provide interoperable or portable instrument drivers because different vendors would use different I/O drivers at the very lowest layer of the software. This forces instrument drivers to be tailored to specific I/O calls for each test station and lowers the likelihood that instrument drivers will be commercially available for each configuration. In addition, standard I/O software allows one to place parameters such as bus addresses and instrument addresses in the instrument driver instead of the test program.
A standard ICM interface enables higher-level software to be interoperable and portable between vendors and across different platforms. This improves the interoperability of test software and the ability to re-host test software from one test system to another. The following specification is mandated:
Emerging Standards
Maintenance Test Data and Services
Maintenance Test Data and Services (MTDs) provide a standard representation of maintenance data in the test environment. MTD enhances runtime execution of the test program by capturing and using information developed during maintenance activities. This directly interfaces with the DIA interface by providing information that can supplement diagnostic capabilities.
Product Design Data
Product Design Data (PDD) originates in the design process and is needed for the development and sustainment of test and diagnostics. PDD includes information about structures that are present in the product solely or principally to support test and diagnostics and facilitates the transfer of information from CAD workstations to the TPS development, reducing errors and development time. PDD supports the back-annotation of test and maintenance information into the design environment, reducing sustainment costs.
Built-In Test Data
Built-in Test Data (BTD) provides a standard representation of Built-in Test (BIT) data into the test environment. BTD will improve runtime execution of test programs by providing guidance to the diagnostic services within an ATS. During TPS development, candidate BIT requirements can be evaluated by contrasting the impact on design and production against maintenance and diagnostic test. Cost-effective BIT requirements can then be imposed as design constraints. New initiatives in the area of BIT architecture and information exchange mechanisms are also being evaluated.
Information Modeling, Metadata, and Information Exchange Standards
Human-Computer Interface Standards
Mandated Standards
There are currently no mandated standards applicable to the ATS Subdomain with respect to Human-Computer Interface Standards as specified in See Human-Computer Interface Standards of the JTA.
Information Security Standards
Mandated Standards
There are currently no mandated standards applicable to ATS with respect to Information Security as specified in See Information Security Standards of the JTA.
Subdomain-Specific Service Areas
Software Engineering Services
There are currently no mandated or emerging standards identified in this section.
Data/Information Services
Platform/Environment Services
Mandated Standards
System Framework Standards
System frameworks provide a common interface for developers of software modules, ensuring that they are portable to other computers that conform to the specified framework. By defining system frameworks, suppliers can focus on developing programming tools and instrument drivers that can be used with any ADE that is compliant with the framework. System frameworks contain, but are not limited to, the following components:
A system designed using a VXI-plug&play system framework ensures that the ADE, DRV, GIC, ICM, and other FRM components are compatible and interoperable with each other. Following the system framework requirements also ensures that all necessary system components have been included, resulting in a complete and operational system. System frameworks increase the likelihood that ADEs will be available on multiple platforms, greatly enhancing the ability to move test software between platforms. While this does not ensure total portability of TPSs, it does eliminate the need to translate or rewrite the source code when it is ported.The following standard is mandated:
Emerging Standards
Receiver/Fixture Interface
The Receiver/Fixture (RFX) and generic pin map interfaces represent a central element of the ATS through which the majority of stimulus and measurement reach the UUT. Standardization of the RFX and pin map allows the same fixture to be used on multiple ATSs. A standard pin map restricts the types of signals present at different positions on the receiver. Standardization of this interface increases the interoperability of test program sets, resulting in lower re-host costs.
Switching Matrix Interface
The Switching Matrix (SWM) interface and ATS receiver/fixture pin map represent a central element of the ATS for connecting ATS instrumentation to the UUT through a switch matrix. The SWM allows a variety of instruments to be connected to multifunction terminals identified by a standard receiver/fixture pin map. The combination of standardizing the SWM interface and a common receiver/fixture pin map gives the ATS the capability to accommodate any fixture that conforms to the pin map. Standardization of the SWM interface and receiver/fixture pin map increases interoperability by ensuring that ATS instruments needed to test a UUT can be switched to pins required by the fixture.
Other Interfaces
The interfaces described in this section are provided for completeness of the ATS Subdomain and to make readers aware that these interfaces have been addressed. Standards for these interfaces are not mandated, because they were not found to be key for the generic open system architecture for ATS.
Computer Asset Controller Interface
The Computer Asset Controller (CAC) interface describes the communication paths between the host computer and instrument controllers in a distributed system. These interfaces may be internal or external to the host computer. Examples of internal interfaces are Industry Standard Architecture (ISA) and Peripheral Component Interface (PCI). Examples of external interfaces are IEEE-488, RS-232, Ethernet, Multisystem Extension Interface, and Modular System Interface Bus.
Host Computer Interface
The Host Computer (HST) interface describes the processing architecture of the primary control computer in which the TPS is executed and through which the operator interfaces. Portions of the HST interface affect the interoperability of ATS. These requirements are included in the Frameworks software interface.
Instrument Control Bus Interface
The Instrument Control Bus (ICB) interface describes the connection between the host computer or instrument controller and the test and measurement instruments in the ATS. Examples of these interfaces are IEEE-488, VME, and VME Extensions for Instrumentation (VXI).
CS.DTS: Defense Transportation System Subdomain
Subdomain Overview
Purpose
The Defense Transportation System (DTS) Subdomain for the Combat Support Domain identifies additions to standards, interfaces, and service areas contained in the Department of Defense (DoD) Joint Technical Architecture (JTA) Core and Combat Support Domain that pertain to the DTS. Also included are additional standards central to the interoperability of existing DTS information systems.
Background
The Defense Transportation System is an integrated cargo- and personnel-delivery system providing worldwide transportation functions for DoD. It consists of 35 core information systems with interfaces to countless DoD, Federal, state government and law-enforcement agencies nationwide. The DTS must be able to readily exchange information with commercial suppliers. Information concerning the 35 DTS systems can be found in the Defense Transportation System Enterprise Architecture, Version 1.0, 31 August 1999 at: <https://business.transcom.mil/J6/j6a/arch1.html> (For use by .mil addresses only).
Subdomain Description
The Transportation System Subdomain includes the information systems, information, personnel, and facilities engaged in providing transportation support functions within DoD. These consist of component systems that support discrete functional areas within the DTS subdomain, such as:
Scope and Applicability
This subdomain applies to all new and existing information systems that make up the Defense Transportation System including upgrades to systems. The standards specified in the JTA Core, the Combat Support Domain, and the Modeling and Simulation Domain, combined with those in this document, comprise the minimum set of standards for the DTS.
Additions to JTA Core and Combat Support Domain
Introduction
This section identifies additional standards (mandatory and emerging) unique to the DTS subdomain of the Combat Support Domain.
Information Processing Standards
Mandated Standards
Product Data Interchange
To promote interoperability among military activities and commercial vendors, DoD has adopted standards endorsed by the commercial industry in lieu of developing unique military standards. The current DoD standards include those adopted for the linear bar code (Code 39 approved November 1982) and 2D bar code (PDF-417, approved July 1995).
Bar code standards are used to easily identify packages and products. Linear bar codes such as AIM BC-1 have limited data storage capability, typically a maximum 17 characters. A two-dimensional (2D) material-handling standard was developed to allow for greater storage, up to 1,850 characters. 2D bar codes can also sustain considerable damage and still be read. ANSI MH10.8.3M describes the use of two-dimensional symbols (e.g., PDF-417) in conjunction with unit loads and transport packages to convey data between trading partners. Additionally, it specifies the structure, syntax, and coding of dates when using two-dimensional symbols. The following standard is mandated:
PDF-417 answers the need to capture, store, and transfer large amounts of data inexpensively. It can exchange complete data files (such as text, numerics, or binary) and encode graphics, fingerprints, shipping manifests, electronic data interchange (EDI) messages, equipment calibration instructions, and much more. It provides a powerful communications capability-- without the need to access an external database.
Information Transfer Standards
There are no mandated or emerging standards for the DTS Information Transfer Standards Section.
Information Modeling, Metadata, and Information Exchange Standards
There are no mandated or emerging standards for the DTS Information Modeling, Metadata, and Information Exchange Standards Section.
Human-Computer Interface Standards
There are no mandated or emerging standards for the DTS Human-Computer Interface Standards Section.
Information Security Standards
Emerging Standards
Internetworking Security Standards
Secure Shell is a protocol used to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. The following Secure Shell standards are emerging:
CS.MED: Medical Subdomain
Subdomain Overview
Purpose
The Medical (MED) Subdomain identifies additions to the standards, interfaces, and service areas contained in the Department of Defense (DoD) Joint Technical Architecture (JTA) Core and Combat Support Domain that pertains to medical systems. These additions are common to the majority of systems in the Medical Subdomain and support the interoperability requirements of those systems.
Background
The Military Health System (MHS), formerly the Military Health Services System (MHSS), is an integrated healthcare delivery system that provides health care to its beneficiary population largely consisting of active-duty personnel and their dependents. It is a global enterprise composed of over 600 military treatment facilities located around the world. The dynamic nature of the MHS, together with the mobility of the beneficiary community, makes it important to ensure that the right information is in the right place at the right time. Furthermore, the MHS requires the ability to exchange this information within DoD, and with other Federal agencies and industry.
The healthcare enterprise is a unique and rapidly evolving industry. Because of this changing environment, it becomes even more critical that the MHS maintain the ability to readily exchange information both within and outside DoD. Within this medical subdomain are established and emerging standards that will be building blocks used in the design, development, and integration of information systems. Standardization is a key enabler within the strategic direction of the MHS information management program to provide support for the business needs of the military healthcare enterprise.
Subdomain Description
The Medical Subdomain includes the information systems, information, personnel, and facilities engaged in providing healthcare and medical support functions within DoD. These consist of component systems that support discrete functional areas within the Medical Subdomain, such as:
Logistics: provision of materiel, facilities, equipment, and technology supporting delivery and management of healthcare services.
These information systems provide the ability to capture, store, transmit, and process medical information at military treatment facilities and other sites around the world. In addition, they interface with commercial medical service providers.
Scope and Applicability
This Subdomain applies to all new and upgraded medical information systems.
The standards specified in the JTA Core and the Combat Support Domain to the JTA, combined with those in this Subdomain, comprise the minimum set of standards for the MHS.
Additions to JTA Core and Combat Support Domain
Introduction
This section identifies additional standards (mandatory and emerging) unique to the Medical Subdomain of the Combat Support Domain.
Information Processing Standards
Mandated Standards
The following medical-specific standards concerning medical Electronic Data Interchange (EDI), retail pharmacy claims EDI, medical still imagery data interchange, and medical information exchange have been identified by the Medical Subdomain in addition to the standards found in the JTA Core and See Introduction of the Combat Support Domain.
Medical Electronic Data Interchange
Health Level Seven (HL7) is a standard for EDI in healthcare environments. It standardizes the format and protocol for the exchange of formatted messages containing medical data among medical software applications. It is to be used for the interchange of medical data, specifically patient records and clinical, epidemiological, and regulatory data. The use of the HL7 standards under these specified conditions is in accordance with Federal Information Processing Standard Publication (FIPS PUB) 161-2, EDI. HL7 standards should not be used for healthcare insurance administrative applications (such as for enrollments, claims, and claim payments) or the Government procurement cycle (such as registration of vendors, requests for quotes, purchase order, shipping notice, or payment advice).
Retail Pharmacy Claims Electronic Data Interchange
The National Council for Prescription Drug Programs (NCPDP) has published a standard for retail pharmacy claims EDI. This standard applies to the transmission of prescription drug and pharmaceutical care benefit/distribution and delivery information including online, real-time drug utilization review, and financial claims data between pharmacies and trading partners.
The following standards are mandated for retail pharmacy claims EDI:
Medical Still Imagery Data Interchange
The Digital Imaging and Communications in Medicine (DICOM) standard describes a means for formatting and exchanging images and associated information. It applies to the operation of the interface used to exchange data among medical imaging devices.
The DICOM standard was developed jointly by the medical user community, represented by the American College of Radiology (ACR), and medical equipment manufacturers, represented by the National Electrical Manufacturers Association (NEMA). It has since been adopted by the European Committee for Standardization (CEN) Technical Committee (TC) 251 and the Japanese Industry Association for Radiation Apparatus (JIRA).
The following standard is mandated for medical still imagery data interchange:
Medical Information Exchange Standards
There are many widely accepted standards for the format and content of medical information to be exchanged among medical-application software entities. In particular, the International Society for Blood Transfusion (ISBT) has developed a standard, ISBT 128, for bar-coding blood donor label information on blood bags. Also, the Universal Product Number (UPN) System, published by the Health Industry Business Communications Council, is a standard for identifying medical and surgical products in the supply chain. Reference the following Health Industry Business Communications Council Web site for more information: <http://www.hibcc.org/upndb.htm> .
The following medical information exchange standards are mandated for the specific purposes indicated:
Emerging Standards
Emerging standards for commercial EDI that are applicable to the Medical Subdomain are discussed below. These standards are added to the emerging information processing standards specified in See Data Management of the JTA Core and Section See Product Data Interchange of the Combat Support Domain.
Commercial Electronic Data Interchange
Final rules implementing the Health Insurance Portability and Accountability Act (HIPAA) will require the use of revised versions of standards for health insurance EDI developed by the ANSI ASC X12 Insurance Subcommittee (X12N).
The following standards are emerging for commercial EDI of some specific transactions for health insurance as published in the Federal Register/Vol. 63, No. 88/Thursday, May 7, 1998/Proposed Rules:
Reference the following Federal web sites for more information on EDI: <http://www.ec.fed.gov/> and <http://www.edi.itsi.disa.mil/> .
Retail Pharmacy Claim Electronic Data Interchange
Final rules implementing the Health Insurance Portability and Accountability Act (HIPAA) require the use of National Council for Prescription Drug Programs (NCPDP) standards for the transmission of prescription drug and pharmaceuticals.
For all health plans (with annual receipts greater than $5 million), including TRICARE, the expected compliance date for use of the HIPAA standard electronic transactions and code sets is no later than 24 months after the effective date of the final rule. (The effective date of the final rule will be 60 days after the final rule is published in the Federal Register.)
Information Transfer Standards
Mandated Standards
There are no information transfer standards applicable to the Medical Subdomain beyond those in See Mandated Standards of the JTA Core and See Information Transfer Standards of the Combat Support Domain.
Emerging Standards
There are no emerging Information Transfer standards applicable to the Medical Subdomain beyond those in See Emerging Standards of the JTA Core and See Information Transfer Standards of the Combat Support Domain.
Information Modeling, Metadata, and Information Exchange Standards
Mandated Standards
There are no information modeling, metadata, and information exchange standards applicable to the Medical Subdomain beyond those in See Mandated Standards of the JTA Core and See Information Modeling, Metadata, and Information Exchange Standards of the Combat Support Domain.
Emerging Standards
There are no emerging information modeling, metadata, and information exchange standards applicable to the Medical Subdomain beyond those in See Emerging Standards of the JTA Core and See Information Modeling, Metadata, and Information Exchange Standards of the Combat Support Domain.
Human-Computer Interface Standards
Mandated Standards
There are no mandated standards for human-computer interfaces (HCIs) applicable to the Medical Subdomain beyond those in See Mandated Standards of the JTA Core and See Human-Computer Interface Standards of the Combat Support Domain.
Emerging Standards
There are no emerging standards for HCIs applicable to the Medical Subdomain beyond those in See Emerging Standards of the JTA Core and See Human-Computer Interface Standards of the Combat Support Domain.
Information Security Standards
Mandated Standards
There are no mandated information security standards applicable to the Medical Subdomain beyond those specified in See Mandated Standards of the JTA Core and See Information Security Standards of the Combat Support Domain. However, the Military Health Services System (MHSS) Automated Information System (AIS) Security Policy Manual , Version 1.0, April 1996, published by OASD(HA), contains information security policies, procedures, and guidance (not standards) for the MHS. System configuration and administration in accordance with the latest version of this document is necessary to ensure the secure operation of the MHS.
Emerging Standards
There are no emerging information security standards applicable to the Medical Subdomain beyond those specified in See Emerging Standards of the JTA Core and See Information Security Standards of the Combat Support Domain. However, as required by HIPAA, Federal regulations governing the security and privacy of medical data are pending.
M&S: Modeling and Simulation Domain
Domain Overview
Purpose
The Modeling and Simulation (M&S) Domain identifies additions to the JTA Core elements (standards, interfaces, and service areas) listed in the JTA Core. These additional standards are key to the Interoperability of M&S within DoD among themselves and real-world systems.
Background
In 1992, DoD established a vision for modeling and simulation, as stated in the DoD M&S Master Plan. "Defense modeling and simulation will provide readily available, operationally valid environments for use by the DoD Components
"Common use of these environments will promote a closer interaction between the operations and acquisition communities in carrying out their respective responsibilities. To allow maximum utility and flexibility, these modeling and simulation environments will be constructed from affordable, reusable components interoperating through an open systems architecture" (Executive Council for Modeling & Simulation).
Department of Defense Directive 5000.59 , DoD Modeling and Simulation (M&S) Management, January 4, 1994; and DoD 5000.59-P, DoD Modeling and Simulation (M&S) Master Plan (MSMP), October 1995, outline DoD policies, organizational responsibilities, and management procedures for M&S and provide a comprehensive strategic plan to achieve DoD's vision of readily available, authoritative, interoperable, and reusable simulations.
Objective 1 of the DoD MSMP states "Provide a common technical framework for M&S" and includes, under sub-objective 1-1, the establishment of "a common high-level simulation architecture to facilitate the interoperability of all types of simulations among themselves and with C4I systems, as well as to facilitate the reuse of M&S components." The efficient and effective use of models and simulations across DoD and supporting industries requires a common technical framework for M&S to facilitate interoperability and reuse. This common technical framework consists of:
The HLA is a progression from the previous architectures and associated standards that have been developed and used successfully for specific classes of simulation. These include Distributed Interactive Simulation (DIS) protocol standards, which support networked, real-time, platform-level virtual simulation; and the Aggregate-Level Simulation Protocol (ALSP), which is used to support distributed, logical-time, constructive simulations. The HLA provides a common architecture for all classes of simulation and, consequently, the HLA supersedes both the DIS and ALSP standards. Transition of simulations from use of other standards is underway in accordance with DoD M&S policy.
Domain Description
This domain provides a set of standards affecting the definition, design, development, execution, and testing of models and simulations. DoD modeling and simulation ranges from high-fidelity engineering simulations to highly aggregated, campaign-level simulations involving joint forces. Increasingly, DoD and supporting industries are integrating and operating a mix of computer simulations, actual warfighting systems, weapon simulators, and instrumented ranges to support a diversity of applications including training, mission rehearsal, operational course of action analysis, investment analysis, and many aspects of acquisition support throughout all phases of the system life cycle. See : JTA Hierarchy Model shows the position of the M&S Domain in the JTA Hierarchy Model.
|
|
Scope and Applicability
The Under Secretary of Defense for Acquisition, Technology, and Logistics (USD[AT&L]) in 1996 designated the HLA as the standard technical architecture for all DoD simulations. The HLA is a technical architecture that applies to all classes of simulations, including virtual simulations, constructive simulations, and interfaces to live systems. The virtual simulation class comprises human-in-the-loop simulators. The constructive simulation class includes wargames and other automated simulations that represent actions of people and systems in the simulation. The live simulation class includes C4I interfaces, weapon systems/platforms with embedded collective training, and instrumented ranges. The method of implementation is at the discretion of the responsible Service, Staff, or Agency.
M&S developed as an integral part of a weapon system or C4I system, or as an embedded simulation, will fall under the mandates of the JTA main body, this domain, and any other applicable domains. Interoperability of embedded simulations will be governed by this domain.
The HLA and related M&S standards listed here address those key technical aspects of simulation design necessary to foster interoperability and reuse, but avoid overly constraining implementation details. They are intended for use in simulations addressing a full range of training, analysis, and acquisition requirements, each of which may have different objectives that dictate different representational details, timing constraints, processing demands, etc. The M&S technical standards in this domain provide the framework within which specific systems, targeted against precise requirements, can be developed. While many of these systems will operate in computational environments considered standard and that fall within the spectrum of the other JTA standards, some may require massively parallel processing or other unique laboratory configurations, bringing with them their own set of requirements. Simulation developers should follow those standards required for the environment in which the simulation is implemented.
Mandates listed in this domain are in addition to those listed in the JTA Core.
Technical Reference Model
There is no separate Technical Reference Model established for the M&S Domain.
Domain Organization
The Modeling and Simulation Domain consists of three sections. M&S.1 contains the overview, Section M&S.2 contains those Information Technology mandated and emerging standards that are additions to the standards contained in the Core, and Section M&S.3 is reserved for those mandates for modeling and simulation that are domain-specific because they do not map directly to the Core service areas.
Additions to the JTA Core
Introduction
The following standards apply in addition to those found in the JTA Core. On September 10, 1996, the Under Secretary of Defense for Acquisition and Technology (USD[A&T]) designated the HLA as the standard technical architecture for all DoD simulations. The HLA, as mandated, is defined by the HLA Rules, the HLA Interface Specification, and the HLA Object Model Template Specification. Compliance criteria have been set forth in the compliance checklist, which was developed as part of the HLA, along with the HLA test procedures. These form the technical basis for HLA compliance. Current versions are listed and available at the Defense Modeling and Simulation Office Web site at <http://www.dmso.mil>.
Information Processing Standards
Introduction
In addition to those mandates for information processing standards described in See Information Processing Standards of the JTA, the following are unique mandates applicable to the Modeling and Simulation Domain.
Mandated Standards
HLA Framework and Rules
The HLA rules comprise a set of underlying technical principles for the HLA. For federations, the rules address the requirement for a federation object model (FOM), object ownership and representation, and data exchange. For federates, the rules require a simulation object model (SOM), time management in accordance with the HLA Runtime Infrastructure (RTI) time management services, and certain restrictions on attribute ownership and updates. The following standard is mandated:
HLA Federate Interface Specification
HLA federates interact with an RTI (analogous to a special-purpose distributed operating system) to establish and maintain a federation and to support efficient information exchange among simulations and other federates. The HLA interface specification defines the nature of these interactions, which are arranged into sets of basic RTI services. On 11 November 1998 the Object Management Group (OMG) Board of Directors adopted the HLA Interface Specification v1.3 (services description and OMG IDL API). The following standards are mandated:
HLA Object Model Template
The HLA Object Model Template (OMT) requires simulations (and other federates) and federations to each have an object model describing the entities represented in the simulations and the data to be exchanged across the federation. The HLA OMT prescribes the method for recording the information in the object models, including objects, attributes, interactions, and parameters, but it does not define the specific data (e.g., vehicles, unit types) that will appear in the object models. The following standard is mandated:
Emerging Standards
The Standards Board of the Institute of Electronic and Electric Engineers (IEEE) voted on September 21, 2000, to accept the HLA as an IEEE standard. As a result of that decision, DMSO is building a Runtime Infrastructure (RTI) to the new HLA 1516.1 specification. Prior to use by the DoD it must be verified. In addition, DMSO produced tools will also be migrated to the 1516 specification. Therefore, the following standards are emerging:
Information Transfer Standards
There are no additional Information Transfer Standards applicable to modeling and simulation beyond those specified in See Information Transfer Standards of the JTA.
Information Modeling, Metadata, and Information Exchange Standards
Introduction
In addition to those mandated standards for Information Modeling, Metadata, and Information Exchange Standards described in See Mandated Standards of the JTA, the following mandated standards are applicable to the Modeling and Simulation Domain.
Mandated Standards
Federation Execution Details Data Interchange Format
This Data Interchange Format (DIF) is the input/output vehicle for sharing HLA initialization data. It contains data from the Federation Object Model as well as additional initialization data needed by the HLA RTI and other HLA initialization tools. The Federation Execution Details (FED) DIF is part of the HLA Interface Specification referenced above. The following standard is mandated:
Object Model Template Data Interchange Format
A data interchange format has been adopted as an input/output vehicle for sharing HLA object models presented in the standard Object Model Template (OMT) among object model developers and users. The following standard is mandated:
Standard Simulator Database Interchange Format
A DoD data exchange standard (MIL-STD-1821) has been adopted as an input/output vehicle for sharing externally created visual terrain simulator databases among the operational system-training and mission-rehearsal communities. The following standard is mandated:
Emerging Standards
Synthetic Environment Data Representation and Interchange Specification (SEDRIS)
SEDRIS facilitates interoperability among heterogeneous information technology applications by providing complete and unambiguous interchange of environmental data. The range of applications addressed in the SEDRIS development includes entertainment, training, analysis, and system acquisition and support for visual, computer-generated active elements, and sensor perspectives. In addition, SEDRIS provides a standard interface for GIS systems, which are key components in the generation of complex integrated databases for simulation applications. The SEDRIS data interchange specification supports the pre-runtime distribution and runtime specification of source data, three-dimensional models, and integrated databases that describe the physical environment for both simulation and operational use. The following SEDRIS standards are emerging:
Object Model Data Dictionary
The Object Model Data Dictionary is being developed to support the development and reuse of Federation Object Models (FOMs) and Simulation Object Models (SOMs). This will greatly reduce the time needed to develop new HLA applications and transition legacy systems to the HLA. Initially, content standards are being developed based on the requirements of several programs that are early adopters of the HLA standards. The early adopter programs cover a broad range of simulation applications from engineering to analysis and multiple levels of aggregation from platform-level (previously addressed by the IEEE 1278.1 Protocol Data Unit standards) to aggregate-unit simulations (previously addressed by the Aggregate-Level Simulation Protocol). The object model requirements of these programs are being consolidated into a common set of data elements, specifying both semantics and syntax. Where existing DoD standards do not exist, they will be developed through the HLA Object Model Data Dictionary process.
Human-Computer Interface Standards
There are no additional Human-Computer Interface standards applicable to modeling and simulation beyond those specified in See Human-Computer Interface Standards of the JTA.
Information Security Standards
There are no additional Information Security standards applicable to modeling and simulation beyond those specified in See Information Security Standards of the JTA .
WS: Weapon Systems Domain
Domain Overview
A weapon system is a combination of one or more weapons with all related equipment, materials, services, personnel, and means of delivery and deployment (if applicable) required for self-sufficiency.5
Purpose
This identifies standards for the Weapon Systems (WS) Domain including information standards and analogous standards applicable to weapon systems.
Background
This domain follows the JTA Core document structure to facilitate the identification and traceability of the Weapon Systems Domain additions to the standards mandated in the main body of the JTA. Therefore, the Weapon Systems Domain consists of three sections including: Domain Overview, Mandated Standards, and Emerging Standards.
Weapon Systems mandated standards result from consensus concerning the need for the standards and the maturity of their commercial implementations within the Weapon Systems Domain or within the majority of its subdomains.
Currently there are sections within the Weapon Systems Domain and its subdomains that do not specify mandated additions to the JTA Core. However, due to their hard real-time and embedded-system requirements, the Weapon Systems Subdomains are evaluating the available real-time standards for possible mandate as additions to each section of the JTA, where appropriate.
Domain Description
Weapon systems have special attributes (e.g., timeliness, embedded nature, space and weight limitation), adverse environmental conditions, and critical requirements (e.g., survivability, low power/weight, and dependable hard real-time processing) that drive system architectures and make system hardware and software highly interdependent and interrelated. The position of the Weapon Systems Domain in the JTA Hierarchy Model is shown in See : JTA Hierarchy Model.
Scope And Applicability
A domain is defined as a distinct functional area that can be supported by a family of systems with similar requirements and capabilities. The Weapon Systems Domain, in conjunction with the JTA Core, establishes the minimum set of rules governing the application of information technology between weapon systems, where a weapon system is defined as a combination of one or more weapons with all related equipment, materials, services, personnel, and means of delivery and deployment (if applicable) required for mission successSee Joint Pub 1-02, DoD Dictionary of Military and Associated Terms, 23 March 1994, as Amended through 1 September 2000.. The Weapon Systems Domain encompasses a subset of the JTA and the specific supporting standards profile. For the purposes of the JTA, the Weapon Systems Domain is that domain whose systems' primary function is that of supporting attack and/or defense against an adversary, and that are intentionally designed to interoperate with other weapon systems and/or with systems external to the Weapon Systems Domain.
The Weapon Systems Domain is applicable to all weapon systems as defined in Joint Pub 1-02.
For the purposes of the JTA, the Weapon Systems Domain is organized into subdomains to facilitate the identification of interoperability standards for common areas while maintaining the systems' primary design function of supporting attack and/or defense against an adversary.
The inclusion or exclusion of subdomains in the Weapon Systems Domain is based upon the domain participants' agreement to include or exclude a candidate. It is important to note that some weapon systems incorporate features/functions associated with more than one subdomain and therefore must consider the applicable standards from the pertinent subdomains. The current weapon systems subdomains are:
Aviation Subdomain - Includes all DoD weapon systems on aeronautical platforms, except missiles--manned and unmanned, fixed-wing, and rotary-wing.
Ground Vehicle Subdomain - Includes all DoD weapon systems on moving ground platforms, except missiles--wheeled and tracked, manned, and unmanned.
Missile Defense Subdomain - Includes any system or subsystem (including associated Ballistic Missile/C4I systems) with a mission to detect, classify, identify, intercept, and destroy or negate the effectiveness of enemy aircraft or missiles before launch or while in flight so as to protect U.S. and coalition forces, people, and geopolitical assets.
Missile Systems Subdomain - Includes Strategic and Theater Ballistic Missile Systems, Cruise Missile Systems, and rocket and missile systems used in diverse Battlefield Functional Areas including Fire Support, Close Combat, and Special Operations.
Munition Systems Subdomain - Includes unmanned, remotely deployed target defeating systems that operate from a fixed position, provide/consume targeting data, have data links to control devices, and engage targets either autonomously or on demand.
Soldier Systems Subdomain - Includes any system or subsystem integrating target location, target identification, target acquisition, enhanced survivability, navigation, position location, enhanced mobility, and command-and-control into a system worn or carried by an individual soldier in performance of assigned duties.
DoD Technical Reference Model
DoD TRM Views
The Weapon Systems Domain and subdomains use both the DoD Technical Reference Model (TRM) Service View and the Interface View, as described in See DoD Technical Reference Model. The Interface View is more applicable to real-time systems. Services are best described by the TRM Services View. Interface standardization in weapon systems is a goal of the Open Systems Joint Task Force (OSJTF) of DoD. Both views are needed to capture all of the standards required for the Weapon Systems Domain and subdomains to operate within the DoD enterprise.
See : DoD Technical Reference Model (DoD TRM) depicts the two distinct views of the TRM. Both views are traceable to the POSIX Open Systems Environment (OSE) Reference Model. The Service View extends the POSIX model by decomposing its entities into the specific applications and services that support DoD information and computing systems. The Interface View is based on the Generic Open Architecture (GOA) framework (SAE AS 4893, 1 Jan. 1996) and provides a context for identifying the characteristics of exchanged information (logical interfaces) and the method or mechanism used for information transport (direct interfaces). A short explanation of the TRM is provided here; however, for more detail, readers are encouraged to review the TRM document.
The Interface View identifies both logical and direct interfaces. A logical interface defines requirements for peer-to-peer interchange of data. It identifies senders, receivers, data types, frequency of exchange, and formats. A direct interface identifies the characteristics of the information transfer medium. Simply stated, logical interfaces define what information is transferred; the direct interfaces define how the information is transferred. Logical interfaces are implemented with direct interfaces.
The Interface View expands the Application Platform entity within the POSIX model to include the three other layers: Systems Services Layer (which contains the Operating System Services and eXtended Operating System Services secondary layers), Resource Access Services Layer, and Physical Resources Layer. The Interface View includes the 4L, 3L, 2L, and 1L for peer-to-peer logical interfaces, and the 4D, 4X, 3X, 3D, 2D, and 1D direct interfaces. The Application Program Interface (API) of the POSIX model is synonymous with the 4D interface, while the External Environment Interface (EEI) is synonymous with the 1L and 1D interfaces treated as a pair. Thus the Interface View complements the Service View by expanding the Application Platform entity, and by providing language to describe both application-to-application logical interfaces, and the Application Platform-to-Application Platform logical interfaces (3L and 2L interfaces).
The Service View, unlike the Interface View, categorizes services available in the Applications Platform. The Application Platform service areas defined by the Service View include both runtime and pre-run-time services. The Service View addresses only 4D API interfaces and 1D/1L EEI interfaces. The Service View does not address 2L, 3L, or 4L peer-to-peer logical interfaces, 3X, 3D, or 2D direct interfaces, nor does it address the Resource Access Services Layer or the Physical Resources Layer.
Section WS.2 uses the Service View and identifies additions to the JTA Core standards, and WS.3 uses the layers identified in the Interface View as a context for classifying interface standards used in weapon system platforms. WS.2 and WS.3 both include emerging standards that represent current standards work within the Weapon Systems Domain.
Performance Environment
One of the most distinctive features of a weapon system is the importance of performance characteristics. Weapon systems are developed to meet stringent operational performance criteria in order to be accurate and lethal; and to survive. In order to emphasize this issue, performance is modeled as a separate external environment entity. At the lower level of TRMs, performance will be an integral part of the services.
Application Hardware Environment
Within weapon systems, embedded-computing hardware and software components are highly interdependent in order to satisfy very demanding requirements. The TRM Service View often does not fit a general-purpose computing model very well. Therefore the TRM Interface View is used to capture such features as interconnect and open systems hardware standards.
Hierarchy of TRM Views
In order to capture the diversity found in weapon subsystem design, a hierarchical approach to TRM Views is being established. From the TRM in See : DoD Technical Reference Model (DoD TRM), the TRM Interface View will extend downward into the Weapon Systems Domain and subdomains to provide the basis for standards identification and traceability.
Domain Organization
This domain is divided into three sections: the Overview in WS.1, the Additions to the JTA Core service areas in Section WS.2, and the domain-specific service areas and interfaces in WS.3. WS.2 follows the JTA Core service-area structure. The structure of WS.3 will evolve as WS-specific service areas are identified and a common structure is coordinated among the other annexes.
Additions to the JTA Core
Introduction
The TRM Interface View provides for sufficient fidelity to identify critical functions, interfaces, and technical issues.
Information Processing Standards
This section applies to mission-area, support application, and application platform service software developed or procured to process information for weapon systems.
Mandated Standards
There are no mandated standards for the Information Processing Standards section.
Emerging Standards
Operating System Services
The OSJTF is sponsoring and synchronizing Weapon Systems Domain involvement in the IEEE POSIX working groups. The following real-time-related standard is emerging:
Real-Time Common Object Request Broker Architecture
The OMG Special Interest Group, Real-Time Common Object Request Broker Architecture (CORBA), is evaluating the need for real-time object-oriented standards and products to support real-time embedded systems. As more information becomes available from this group, the Weapon Systems Domain will consider adopting the standards as additions to the JTA information processing standards.
Information Transfer Standards
There are no mandated or emerging standards for the Information Transfer Standards section.
Information Modeling, Metadata, and Information Exchange Standards
This section fosters information exchange among Weapon Systems during their development and maintenance phases. During concept exploration and development, a large number of information elements, objects, and artifacts are generated. If these elements, objects, and artifacts are shared across weapon system developments, considerable resources can be saved.
Real-time, embedded-processing systems must be developed within a development support environment for an entire system. As such, they must integrate into a systems-engineering process that culminates in prototype or production weapon systems that meet specific functional and performance requirements.
Mandated Standards
There are no mandated standards for the Information Modeling, Metadata, and Information Exchange standards.
Human-Computer Interface Standards
This section provides a common framework for Human-Computer Interfaces (HCI) design and implementation in weapon systems. The objective is to standardize user interface design and implementation options across weapon systems, thus enabling applications within the Weapon Systems Domain to appear and behave consistently, resulting in higher productivity, shorter training time, and reduced development, operation, and support costs besides influencing commercial HCI development. This version mandates the design of graphical and character-based displays and controls for weapon systems.
In order to identify appropriate systems to use for baseline characterization, the following working definition for time criticality is used: "Systems where no perceptible delay exists between the time an event occurs and the time it is presented to the user; and where there is an operational requirement for the user to quickly recognize this presentation, comprehend its significance, and determine and execute appropriate action(s)."
There are some aspects of HCIs that can be common across the Weapon Systems Domain, while others are subdomain-specific. Hence, an HCI style guide is required at the weapon systems level, and currently for each subdomain.
Mandated Standards
There are no mandated standards additions for the Human-Computer Interface Standards section.
Emerging Standards
The Weapon Systems Human-Computer Interface (WSHCI) Style Guide addresses guidelines applicable across most or all of the Weapon Systems Domain. It provides a starting point for the development of the subdomain-specific style guides that will further the goal of standardization. Also, the WSHCI Style Guide provides design guidance based on lessons learned and best practices from past HCI efforts. However, the WSHCI Style Guide does not provide the level of design guidance needed to attain a common behavior and appearance. This is left to the subdomain-specific style guides. The following U.S. Army document is proposed as the starting point to become the joint weapon system style guide and is an emerging standard:
Domain-Specific Service Areas and Interfaces
Introduction
The Interfaces View of the TRM, depicted in See : DoD Technical Reference Model (DoD TRM), provides sufficient fidelity for identifying classes of interfaces to apply open systems interface standards to the design of real-time and embedded-hardware/software systems. The Interface View also facilitates the identification of critical functions and interfaces within the real-time and embedded-computing systems of the Weapon Systems Domain.
This section provides a common framework identifying mandated and emerging embedded-computing interface standards associated with the logical and direct interface classes defined for the layers depicted in the TRM.
Only those layers of the TRM that have subdomain-specific mandated or emerging standards identified are addressed in this section.
Application Software Layer Interfaces
There are no additional mandated or emerging standards for the Application Software Layer Interfaces section.
System Services Layer Interfaces
There are no additional mandated or emerging standards for the System Services Layer Interfaces section.
Resource Access Services Layer Interfaces
There are no additional mandated or emerging standards for the Resource Access Services Layer Interfaces section.
Physical Resources Layer Interfaces
Mandated Standards
There are no mandated standards for the Physical Resources Layer Interfaces section.
Combat Identification Services
Combat Identification (CI) is the process of obtaining an accurate characterization of entities in a combatant's area of responsibility to the extent that high-confidence, real-time application of tactical options and weapon resources can occur (approved Joint Combat Identification Master Plan, August 1995).
The increased lethality of weapon systems and the increase in the speed and ferocity with which air and land battles are fought have resulted in a greater need for capabilities that will aid warfighters in reducing fratricide. Positive visual identification of friends and foes (IFF) during battles fought under degraded natural and man-made conditions is difficult at best when opposing forces use dissimilar equipment and tactics to those of our own forces. However, our modern world of changing alliances and the use of multi-national forces in United Nations (UN) peacekeeping efforts to quell geopolitical disturbances has made a difficult problem even tougher because friends and foes alike are now using identical combat platforms, creating a situational awareness (SA) nightmare.
Identification Friend or Foe
The primary function of Identification Friend or Foe (IFF) is to establish the identity of all friendly systems within the surveillance volume of surface-to-air, air-to-air, and some air-to-ground Weapon System platforms. The need for Friend identification is to permit tactical action against all Foe (non-friendly) systems and to avoid tactical action against Friendly systems. This need is a key element in modern combat, as an object detected by a sensor, even beyond visual range, has to be identified and classified as early as possible so that, if necessary, either an appropriate defense can be prepared against the Foe or that steps can be taken to prevent the Friend from being engaged/attacked by Friendly forces.
Mandated Standards
The following standards are mandated for new and upgraded Weapon Systems platforms requiring integrated or appliqué IFF capabilities:
Aeronautical Telecommunications: Appendix 10 to the Convention on International Civil Aviation , volume IV (Surveillance Radar and Collision Avoidance Systems), Edition 1, International Civil Aviation Organization (ICAO): Montreal, 1995, with Supplements (31 May 1996 and 10 November 1997).
DOT FAA 1010.51A , US National Aviation Standard for the Mark X (SIF) Air Traffic Control Radar Beacon system (ATCRBS) Characteristics, 8 March 1971.
The following mandated standard provides a general description of required capabilities for military IFF systems:
The following mandated standard defines the required anti-jamming capabilities of military IFF systems:
The following mandated standard defines the required characteristics/capabilities of installed military IFF systems:
The following mandated standard defines the required characteristics of military IFF systems to provide Mode S capabilities:
WS.AV: Aviation Vehicles Subdomain
NOTE: The standards and guidelines contained in this Subdomain are precedent for aviation systems as prepared by the Joint Aeronautical Commanders Group (JACG), Aviation Engineering Board (AEB), and Interoperability Subboard (ISB).
Aviation Subdomain Overview
The Aviation Subdomain has been created with the intention that it will be the principal reference for Service Acquisition Executives, Program Executive Officers, and aviation Program teams to identify interoperability standards for aviation systems. In consonance with this reasoning, all relevant standards that are found in higher tier sections (the Core and the Weapon Systems Domain) of the Joint Technical Architecture (JTA) have been absorbed into the body of this document. All standards in this subdomain are designated "preferred"; which means that they should be given first consideration while addressing interoperability requirements (see section See Preferred Standards Selection Process). These standards should be applied in consonance with Performance-Based Business Environment (PBBE) principles, and within the context of the Performance-Based Systems Engineering Process.
Purpose
This subdomain identifies preferred standards applicable to external (skin-to-skin) interfaces for DoD aviation weapon systems that enable system-to-system interoperability, including airborne-to-airborne/space/surface (afloat)/ground interfaces. Adoption of external interface standards facilitates interoperability, and is recognized as a necessary part of the systems engineering process to ensure that the system's interoperability requirements are properly addressed.
Background
Preferred standards listed in section See Aviation Subdomain Preferred Interoperability Standards of this subdomain are based on work performed by the Aviation Subdomain Working Group (AVSDWG) for the Joint Aeronautical Commanders Group Aeronautical Engineering Board Interoperability Subboard. AVSDWG membership consists of representatives from the military Services, the United States Coast Guard, the Federal Aviation Administration, and aerospace industry.
Scope and Applicability
The Aviation Subdomain is applicable to all DoD aviation weapon systems. These include both fixed-wing and rotary-wing aircraft (manned and unmanned), and exclude missiles and missile defense systems (which are covered elsewhere in the Weapon Systems Domain of the JTA). Specifically excluded are interoperability standards that apply to other JTA domains/subdomains such as C4I and munitions. These standards do not fit within the scope of the JTA "minimum set" concept.
Subdomain Organization
This subdomain is divided into four sections: See Aviation Subdomain Overview, Overview; See Aviation Subdomain Preferred Interoperability Standards, Preferred Standards; See Aviation Subdomain "Other JTA" Standards, Other JTA Standards; and See Aviation Subdomain Terms, Definitions and Acronyms, Terms, Definitions and Acronyms. Four distinct Aviation Subdomain functional areas have been defined: Communications, Data Links, Navigation/Landing Aids, and Identification Aids. Aviation Subdomain preferred standards have been grouped into these four functional areas.
Preferred Standards Selection Process
Preferred standards have been selected by the AVSDWG in accordance with the JTA Aviation Subdomain Preferred Standards Selection Process (See : JTA Aviation Subdomain Preferred Standards Selection Process). Standards were screened to ensure that they enable interoperability among and between DoD aviation weapon systems, including associated airborne-to-airborne, space, surface (afloat), and ground interface elements. The Aviation Subdomain Preferred Standards List (section See Aviation Subdomain Preferred Interoperability Standards) contains standards that meet interoperability requirements and meet the "best fit" groundrules, i.e. "forward looking" and "open." Standards that do not meet interoperability requirements and/or do not meet the "best fit" ground rules, but are found elsewhere in the JTA, are regarded as "other JTA standards" as explained in section See Aviation Subdomain "Other JTA" Standards. Only systems and technologies that have associated standards have been included.
|
|
Best Fit Ground Rules
Aviation Subdomain preferred standards include the minimum set of standards required to enable system-to-system interoperability. In addition, Aviation Subdomain preferred standards must also be forward looking and/or open. Forward looking is considered a higher priority in selecting preferred standards. In addition, only standards that address an external interoperability requirement are considered for this subdomain.
Forward Looking
Forward looking standards are those required to enable interoperability on future DoD aviation weapon systems and major upgrades to existing systems. Legacy standards are considered forward looking if they are required for future systems. If a legacy standard is no longer required for future aviation weapon systems, it would be removed from the preferred list; however, it may still meet specific performance-based requirements.
Open
Open standards are widely used, preferably international, preferably consensus-based, preferably in the public domain, and well defined (verifiable). To be considered open, a standard does not have to meet all criteria listed. These criteria are listed below in priority order for consideration in selecting preferred standards.
Widely Used
Widely used is conceptual in nature and as a result difficult to define. There can be a wide range of users, from one to thousands. Typically, the concept requires some judgement; e.g., if there are two standards, and one has a single user and the other has multiple users, the standard with multiple users would be preferred.
International
Standards that are accepted by more than one nation or international organizations are preferred.
Consensus Based
Consensus based means that more than one entity, or a standard development organization representing more than one entity, has agreed upon or promulgated the standard.
Aviation Subdomain Preferred Interoperability Standards
This section identifies the preferred interoperability standards for the Aviation Subdomain. It is divided into four distinct service areas for aviation platform interoperability: Communications, Data Links, Navigation/Landing Aids, and Identification Aids. Preferred standards that are duplicated elsewhere in the DoD JTA are marked "" for mandated standards and "-" for emerging standards. Standards that are unique to the Aviation Subdomain are marked "♠".
Communications
Military Satellite Communications
Military Satellite Communications (MILSATCOM) systems include those systems owned or leased and operated by DoD and those commercial satellite communications (SATCOM) services used by DoD. The basic elements of satellite communications are a space segment, a control segment, and a terminal segment (air, ship, ground, etc.). An implementation of a typical satellite link will require the use of satellite terminals, a user communications extension, and military or commercial satellite resources.
For 5-kHz or 25-kHz single-channel access service supporting the transmission of either voice or data:
For 5-kHz Demand Assigned Multiple Access (DAMA) service, supporting the transmission of data at 75 to 2400 bps and digitized voice at 2400 bps:
For 25-kHz Time Division Multiple Access (TDMA)/DAMA service, supporting the transmission of voice at 2,400, 4,800, or 16,000 bps and data at rates of 75 to 16,000 bps:
For data controllers operating over single-access 5-kHz and 25-kHz UHF SATCOM channels:
This standard describes a robust link protocol that can transfer error-free data efficiently and effectively over channels that have high error rates.
For MILSATCOM equipment that control access to DAMA UHF 5-kHz and 25-kHz MILSATCOM channels:
Radio Communications
High Frequency
For both Automatic Link Establishment (ALE) and radio subsystem requirements operating in the High Frequency (HF) bands:
Very High Frequency
For radio subsystem requirements operating in the Very High Frequency (VHF) bands:
Ultra High Frequency
For radio subsystem requirements operating in the Ultra High Frequency (UHF) bands:
Combat Net Radio
The Combat Net Radio (CNR) network supports the Army battlefield. It uses existing radio waveforms to physically transmit the data for airborne and mobile ground users. The following standards define CNR interoperability requirements at present:
Global Air Traffic Management - Communications
This section addresses civil Air Traffic Management (ATM) interoperability for DoD aircraft in order to operate in the evolving global civil aviation airspace arena. This evolution is the result of the International Civil Aviation Organization (ICAO), and its associated Civil Aviation Authorities' (CAA's) desires to take advantage of advancements in the areas of Communications, Navigation, and Surveillance (CNS) technologies. The purpose is to move from a system of ground-based air traffic control to an integrated system of ATM. As a result, DoD aircraft must conform, where required, to appropriate civil requirements and industry standards to meet future civil airspace requirements. These aircraft must be properly equipped to operate in the defined civil aviation regulated airspace environment, and accommodate its evolution. If not, they will be unable to operate safely and effectively in airspace in which new separation standards and ATM procedures are being implemented by civil aviation authorities. Such aircraft may be provided passage in the airspace but may encounter non-optimal routes and traffic delays according to Euro Control documents or may be excluded from operating in that airspace. The focus of this section is on communications and information-transfer standards for civil ATM interoperability.
The following Air Traffic Management Interoperability Standards covering VHF Digital Link Mode 2, HF Data Link, Aeronautical Mobile Satellite Services, Traffic Alert and Collision Avoidance System (TCAS), and Mode S capabilities needed to interoperate with civil communications infrastructures are considered preferred standards:
RTCA DO-210C, Minimum Operational Performance Standards for Aeronautical Mobile Satellite Services (AMSS), 16 January 1996.
Area Navigation
FAA Advisory Circular (AC) No. 90-96, Approval of U.S. Operators and Aircraft to Operate Under Instrument Flight Rules (IFR) in European Airspace Designated for Basic Area Navigation (BRNAV/RNP-5), 20 March 1998.
Data Links
Link 4A
Link 4A is used in combat direction systems and Link 4A controlled aircraft. It is also used for aircraft carrier deck landings (Navy only).
Navigation/Landing Aids
Global Positioning
The CJCS (CJCSI 6130.01A, 1998 CJCS Master Positioning, Navigation, and Timing Plan) has declared that the GPS will be the primary radio navigation source of positioning, navigation and timing (PNT) for the DoD. GPS is a space-based, worldwide, precise positioning, velocity, and timing system. It provides an unlimited number of suitably equipped passive users with a force-enhancing, common-grid, all-weather, continuous, three-dimensional PNT capability.
Global Air Traffic Management - Navigation
The following civil global navigation standards provide interoperability for DoD aircraft to navigate and land in the evolving global civil aviation airspace arena. Two types of global navigation satellite augmentation have been standardized by ICAO - the Space-Based Augmentation System (SBAS) and the Ground-Based Augmentation System (GBAS). These are known in the US as Wide Area Augmentation System (WAAS) and Local Area Augmentation System (LAAS), respectively. Interoperability standards include ICAO Annex 10 documentation and RTCA standards as well as specific operational approval documents such as FAA Advisory Circulars (AC). Compliance or equivalence with these standards is necessary for authorized IFR operations.
ICAO SARPs, Aeronautical Telecommunications, Annex 10 to the Convention on International Civil Aviation. Proposed SARPs for the Global Navigation Satellite System (GNSS), Space-Based Augmentation System (SBAS), and Ground-Based Augmentation System (GBAS), DRAFT, 9 June 2000.
FAA AC No. 90-94, Guidelines for Using GPS Equipment for IFR En Route & Terminal Operations & for Nonprecision Instrument Approaches in the U.S. National Airspace System, 14 December 1994.
FAA AC No. 90-96, Approval of U.S. Operators and Aircraft to Operate Under Instrument Flight Rules (IFR) in European Airspace Designated for Basic Area Navigation (BRNAV/RNP-5), 20 March 1998.
FAA Order 8400.12A, Required Navigation Performance 10 (RNP-10) Operational Approval, 9 February 1998.
FAA Notice 8110.60, GPS as a Primary Means of Navigation for Oceanic/Remote Operations, 4 December 1995.
RTCA DO-228, Minimum Operational Performance Standards for Global Navigation Satellite Systems (GNSS) Airborne Antenna Equipment, 20 October 1995.
RTCA DO-229B, Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System Airborne Equipment, 6 October 1999.
RTCA DO-245, Minimum Aviation System Performance Standards for Local Area Augmentation System (LAAS), 28 September 1998.
RTCA DO-246A, GNSS-Based Precision Approach Local Area Augmentation System (LAAS) - Signal-in-Space Interface Control Document (ICD), 11 January 2000.
Landing Aids
Instrument Landing Aids
ICAO International Standards and Recommended Practices (SARPs), Aeronautical Telecommunications, Annex 10 to the Convention on International Civil Aviation, Volume I (Radio Navigation Aids), July 1996.
Microwave Landing Aids
ICAO International Standards and Recommended Practices (SARPs), Aeronautical Telecommunications, Annex 10 to the Convention on International Civil Aviation. Volume I (Radio Navigation Aids), July 1996.
EUROCAE ED-36A, Minimum Operational Performance Specification for Microwave Landing System (MLS) Airborne Receiving Equipment, January 1995.
GPS Landing Aids
ICAO International Standards and Recommended Practices (SARPs), Aeronautical Telecommunications, Annex 10 to the Convention on International Civil Aviation. Proposed SARPs for the Global Navigation Satellite System (GNSS), Space-Based Augmentation System (SBAS), and Ground-Based Augmentation System (GBAS), DRAFT, 9 June 2000.
RTCA DO-228, Minimum Operational Performance Standards for Global Navigation Satellite Systems (GNSS) Airborne Antenna Equipment, 20 October 1995.
RTCA DO-229B, Minimum Operational Performance Standards for Global Positioning System/ Wide Area Augmentation System Airborne Equipment, 6 October 1999.
RTCA DO-245, Minimum Aviation System Performance Standards for Local Area Augmentation System (LAAS), 28 September 1998.
RTCA DO-246A, GNSS-Based Precision Approach Local Area Augmentation System (LAAS) - Signal-in-Space Interface Control Document (ICD), 11 January 2000.
RTCA DO-253, Minimum Operational Performance Standards for GPS Local Area Augmentation System Airborne Equipment, 11 January 2000.
Identification Aids
Identification Friend or Foe
The primary function of Identification Friend or Foe (IFF) is to establish the identity of all friendly systems within the surveillance volume of surface-to-air, air-to-air, and some air-to-ground weapon systems. The need for friend identification is to permit tactical action against all foe (non-friendly) systems and to avoid tactical action against friendly systems. This need is a key element in modern combat, as an object detected by a sensor, even beyond visual range, has to be identified and classified as early as possible. This is so that, if necessary, either an appropriate defense can be prepared against the foe or that steps can be taken to prevent the friend from being engaged/attacked by friendly forces.
FAA 1010.51A, US National Aviation Standard for the Mark X (SIF) Air Traffic Control Radar Beacon System (ATCRBS) Characteristics, 8 March 1971.
STANAG 4193, Part 1, NATO Standard Agreement Technical Characteristics of IFF Mk XA and Mk XII Interrogators and Transponders, Edition 2, 12 November 1990, with Amendment 1, 15 December 1997.
STANAG 4193, Part 2, (SECRET), NATO Standard Agreement Technical Characteristics of IFF Mk XA and Mk XII Interrogators and Transponders, Edition 1, 12 November 1990.
STANAG 4193, Part 3, NATO Standard Agreement Technical Characteristics of IFF Mk XA and Mk XII Interrogators and Transponders, Edition 1, 12 November 1990, with Amendment 1, 31 January 1995.
STANAG 4193, Part 4, NATO Standard Agreement Technical Characteristics of IFF Mk XA and Mk XII Interrogators and Transponders, 28 November 1997.
STANAG 4193, Part 5, Annex A through D, (SECRET NATO RESTRICTED), NATO Standard Agreement Technical Characteristics of IFF Mk XA and Mk XII Interrogators and Transponders, 4 September 1998.
Traffic Alert and Collision Avoidance
ARINC 735-2, Traffic Alert and Collision Avoidance System (TCAS), (Includes Supplements 1 and 2), January 1993.
RTCA DO-185A, VOL I, Minimum Operational Performance Standards for Traffic Alert and Collision Avoidance System II (TCAS II) Airborne Equipment Volume I, 16 December 1997.
Aviation Subdomain "Other JTA" Standards
All JTA Standards not listed in the Aviation Subdomain Preferred Standards list (sections See Communications - See Identification Aids) are "other JTA" standards. The use of other JTA standards on DoD aviation weapon systems is encouraged when a standard can meet a stated or derived requirement. (See step 3 of the Program Standards Selection Process.)
Aviation Subdomain Terms, Definitions and Acronyms
The following terms have not been sufficiently defined elsewhere, or are easily mis-understood. Their definitions appear here for clarification.
Performance-Based Business Environment (PBBE)
PBBE is a "state of being" where government customers and contractors/suppliers jointly capitalize on commercial practice efficiencies to improve the acquisition and sustainment environment. In this new environment, solicitations and contracts describe system performance requirements in a way that permits contractors greater latitude than under historical acquisition methods to use their own design and manufacturing ingenuity to meet needs. Additionally, suppliers will compete and be selected based on their proposed approaches, process effectiveness, and prior performance.
Verifiable
Verification includes substantiation that performance requirements have been satisfied as well as confirmation that delivered products exhibit functionally equivalent performance to the qualified design. This is accomplished through the use of product acceptance criteria that are developed as part of the engineering development effort. Interface standards should include rigorously defined verification criteria. For electronics and software, a "gold standard" is often used to verify that performance requirements have been achieved.
WS.GV: Ground Vehicle Subdomain
Subdomain Overview
A weapon system is a combination of one or more weapons with all related equipment, materials, services, personnel, and means of delivery and deployment (if applicable) required for self-sufficiency.
Systems covered within the Ground Vehicle (GV) Subdomain include all DoD weapon systems on moving ground platforms except missiles--wheeled and tracked, manned and unmanned.
Purpose
This subdomain identifies standards for the Ground Vehicle Subdomain of the Weapon Systems Domain including information standards and analogous standards applicable to ground vehicle systems.
Background
The standards in this subdomain are based on the work performed by the Army Weapon Systems Technical Architecture Working Group (WSTAWG).
Scope And Applicability
The scope of this subdomain is the entire Ground Vehicle Subdomain as defined in WS.GV.1.
Technical Reference Model
The Technical Reference Model used in this subdomain is the Technical Reference Model (TRM), which is described in the Weapon Systems Domain. The TRM Service View and Interface View are used as applicable.
Subdomain Organization
This Subdomain is divided into three sections: the Overview in WS.GV.1, the additions to the JTA Core standards in WS.GV.2, and the Subdomain-Specific Services in WS.GV.3. WS.GV.2 follows the JTA Core service area structure. The structure of WS.GV.3 will evolve as ground vehicle-specific service areas are identified and a common structure is coordinated among the other domain and subdomains.
Additions to the JTA Core
Introduction
This section identifies standards for the Ground Vehicles Subdomain in addition to the standards in the JTA Core.
Information Processing Standards
There are no mandated or emerging standards for the information processing Standards section.
Subdomain-Specific Service Areas and Interfaces
Introduction
The Interfaces View of the TRM, depicted in, provides sufficient fidelity for identifying classes of interfaces to apply open systems interface standards to the design of real-time and embedded hardware/software systems. The Interface View also facilitates the identification of critical functions and interfaces within the real-time and embedded-computing systems of the Ground Vehicle subdomain. See : DoD Technical Reference Model (DoD TRM)
This section provides a common framework identifying mandated and emerging embedded-computing interface standards associated with the logical and direct interface classes defined for the layers depicted in the TRM.
Only those layers of the TRM that have subdomain-specific mandated or emerging standards identified are addressed in this section.
Application Software Layer Interfaces
There are no additional mandated or emerging standards for the Application Software Layer Interfaces section.
System Services Layer Interfaces
There are no mandated or emerging standards for the System Services Layer Interfaces section.
Resource Access Services Layer Interfaces
There are no mandated or emerging standards for the Resource Access Services Layer Interfaces section.
Physical Resources Layer Interfaces
Mandated Standards
MIL-STD-1553B , Standard for Medium Speed System Network Bus, 21 September 1978, with Notice of Change 1, 12 February 1980; Notice of Change 2, 8 September 1986; Notice of Change 3, 31 January 1993; and Notice of Change 4, 15 January 1996.
IEEE 1101.2 , Standard for Mechanical Core Specifications for Conduction-Cooled Eurocards (ANSI), 1992.
EIA 330 , Electrical Performance Standards for Closed Circuit Television Camera 525/60 Interlaced 2:1 (ANSI/EIA 330-68), November 1966.
The unique mission requirements of Ground Vehicle Systems dictate system and environmental constraints (e.g., long battery life, low power consumption, small size, light weight, shock-resistant, critical EMI-shielded constraints, all-weather operation) that make current the state-of-the-art digital and/or color video equipment unsuitable for use with Ground Vehicle Systems. Therefore, the following standards are mandated for Ground Vehicle Systems employing analog and/or monochrome video technology:
Emerging Standards
The Ground Vehicle Systems Subdomain is also evaluating the Controller Area Network Bus (CANBUS) protocol and Class C networks documented in Society of Automotive Engineers (SAE) J1939 as an emerging standard for use in its heavy trucks and off road vehicles:
SAE J1708 defines a general-purpose serial data communications link that may be utilized in heavy-duty vehicle applications. It is intended to serve as a guide toward standard practice to promote serial communication compatibility among microcomputer-based modules. This standard requires the definition of the data format, message identification, message priorities, error detection (and correction), maximum message length, percent bus utilization, and methods of physical adding/removing units to/from the line for the particular application. The following standard is emerging for ground vehicles:
SAE J1587 defines the format of the messages and data being communicated between microprocessors used in heavy-duty vehicle applications. It is meant to serve as a guide toward standard practice software compatibility among microcomputer based modules. This Standard is to be used with SAE J1708 that defines the requirements for the hardware and basic protocol that is needed to implement the requirements of SAE J1587. The following standard is emerging for Ground Vehicles:
WS.MD: Missile Defense Subdomain
Subdomain Overview
A weapon system is a combination of one or more weapons with all related equipment, materials, services, personnel, and means of delivery and deployment (if applicable) required for self-sufficiency.
Systems covered within the Missile Defense Subdomain include any system or subsystem (including associated Ballistic Missile/C4I systems) with a mission to detect, classify, identify, intercept, and destroy or negate the effectiveness of enemy aircraft or missiles before launch or while in flight so as to protect U.S. and coalition forces, people, and geopolitical assets.
Purpose
This JTA subdomain identifies standards for missile defense systems. This version is focused primarily on active ballistic missile defense, with the intent of expanding this subdomain in the future.
Background
The following documents provide useful background information regarding missile defense (sorted by title), with particular emphasis on ballistic missile defense:
Draft Ballistic Missile Defense (BMD) Command, Control, and Communications (C3) Operational Requirements Document (ORD) (U) , Air Force Space Command, AFSPC002-97-1, Working Draft, 1 April 1998, Secret (U.S. Only).
Battle Management Concept for Joint Theater Air and Missile Defense Operations, Joint Theater Air and Missile Defense Organization (JTAMDO) , Final Draft, 11 September 1997.
BMD C3 ORD Requirements Incorporations into the NMD ORD (U) , Air Force Space Command, 30 July 1998, Secret.
Capstone Theater Missile Defense (TMD) Cost and Operational Effectiveness Analysis (COEA) , BMDO, 1996. Doctrine for Joint Theater Missile Defense. Joint Pub 3-01.5. February 22, 1996.
FY96 Analysis Of The Ballistic Missile Defense Interoperability Standards , Fife et al., IDA-P-3277, Alexandria, VA: Institute For Defense Analyses.
JTAMD Mission Area Assessment (U) , DoD J8, Draft, October 30, 1997, Secret. (Note that this document combines the capstone TMD COEA, TAD, and information on land attack cruise missiles).
National Ballistic Missile Defense (NBMD) Capstone Requirements Document (CRD) (U) , U.S. Space Command, August 24, 1996, Secret (Release Can-US).
NMD Capability 1 and Capability 2 System Requirements Document (U) , TRW Inc., May 6, 1998, BMC3 SE&I, Rosslyn, VA: TRW, Secret.
NMD Capability 2 System Requirements Document (U) , TRW Inc., April 4, 1997, BMC3 SE&I, Rosslyn, VA: TRW, Secret.
Operational Requirements Document (ORD) for National Missile Defense (NMD) (U) , draft, US Army Space and Strategic Defense Command, March 10, 1997, Secret.
Theater Air and Missile Defense Architecture for Joint Force Operations , Bean et al., June 1997, MP 97W 105.
Theater Air and Missile Defense Master Plan , September 1997, JTAMDO. POET control number MCNEIL 000396/97.
Subdomain Description
For a description of this subdomain, see the background material in WS.MD.1.2. As discussed in some of these documents, there is a need for interoperability between Theater Missile Defense (TMD) family of systems (FoS), National Missile Defense (NMD) components, and other systems such as Space-Based Infrared System (SBIRS) to support their missions. Such interoperability would need to support activities such as minimum cueing, track exchange, and weapon coordination. This requires standards (e.g., in how such information should be transferred and on geospatial values). This JTA subdomain specifies such standards to support interoperability to fulfill missile-defense mission objectives.
Scope and Applicability
The scope of this subdomain is the entire domain of missile defense (as defined in the overview above). However, the standards listed within this version of the subdomain solely address support for active and passive defense6 against theater and strategic ballistic missiles in flight, as a first step in evolving a comprehensive and complete set of standards for all missile defense systems. It is acknowledged that this evolution will require interaction with many communities to resolve standardization issues.
Technical Reference Model
Missile defense systems typically include one or more sensors, one or more weapons, and a communication infrastructure all coordinated by a Battle Management Command, Control, and Communications (BMC3) system (which also coordinates with external systems). At this time there is ongoing work to develop a tailored reference model and technical architecture profile for missile defense based on the TRM.
Subdomain Organization
This subdomain is divided into three sections: (1) the Overview in WS.MD.1; (2) the missile defense mandates and emerging standards additional to those in the JTA Core in WS.MD.2; and (3) the Subdomain-Specific Service Areas and Interfaces in WS.MD.3. WS.MD.2 follows the JTA Core service area structure. The structure of WS.MD.3 will evolve as missile defense-specific service areas are identified and a common structure is coordinated among the other domains.
Additions to the JTA Core
Introduction
This section identifies standards for the Missile Defense Subdomain that are additional to standards in the JTA Core.
Information Processing Standards
Emerging Standards
Navigation Standard
The following standard supports sharing of navigation-related data (e.g., position, velocity, and time) between missile defense systems. This standard is consistent with, and extends the mandates in, the JTA Core (in particular World Geodetic System [WGS84] and Coordinated Universal Time [UTC] U.S. Naval Observatory [USNO]). The following standard is emerging:
Real-Time Defense Information Infrastructure Common Operating Environment (DII COE)
Missile defense systems are, by their nature, a combination of hard and soft real-time systems. There is ongoing work to incorporate some soft real-time capabilities into the DII COE. The applicability of these capabilities is being evaluated.
Information Transfer Standards
Mandated Standards
Time Synchronization
The time basis for NMD and TMD operations shall be UTC (USNO) as disseminated by the Navstar Global Positioning System (GPS). The GPS standards identified in See Global Positioning System are mandated.
Emerging Standards
Joint Range Extension (JRE) Application Protocol (JREAP)
The Joint Range Extension (JRE) application protocol (JREAP) encapsulates TADIL information (e.g., TADIL-J/Link-16) as an application layer within Joint Technical Architecture (JTA) compliant data protocols (e.g., Internet Protocol (IP), Point-to-Point Protocol (PPP), Ultra High Frequency Demand Assigned Multiple Access (UHF DAMA)). The joint protocol allows a JRE Gateway to process and manage incoming TADIL messages and redirect them to the appropriate destination via the appropriate media. The following standard is emerging for exchange of TADIL-J information over long haul media:
Information Modeling, Metadata, and Information Exchange Standards
Mandated Standards
Bit-Oriented Formatted Messages
The Tactical Digital Information Link (TADIL)-J/Link-16 message format is mandated as a mobile interoperable communication message format on all transportable missile defense systems, and for Theater Air Missile Defense (TAMD) systems that must interoperate with them. This is specified by MIL-STD-6016A combined with all accepted Interface Change Proposals (ICPs) awaiting incorporation. Although this standard is in the JTA Core, this subdomain adds the additional requirement that this standard must be implemented for such systems and cannot be replaced with the alternatives listed in the JTA Core. Such systems may also support other message formats. The following standard is mandated for transportable missile defense systems.
Emerging Standards
The Missile Defense Data Standardization Group is working to merge the Data Element Definitions (DEDs) developed for TMD, NMD, and the Joint Theater Air Missile Defense Organization (JTAMDO).
The NMD program is in the process of selecting communication mechanisms. An Integrated Product Team (IPT) formed to study the issue has recommended that NMD use a Variable Message Format (VMF)-based message set.
Ballistic Missile Defense Organization (BMDO) has formed the "Time and Geospatial Working Group" (TGWG) to identify additional time and geospatial issues and to develop cross-system resolutions of those issues.
Human-Computer Interface Standards
Mandated Standards
Symbology
Operations can be identified as being engagement operations or force operations. Engagement operations are real-time or near-real-time operations involved in control of the engagement, providing for the acquisition, tracking, identification, management and dissemination of air track information, the alerting of the force to the presence of non-friendly aircraft, the cueing of weapon systems to engageable aircraft in their area of interest and for the distribution of battle management information. Engagement operations are typically supported by TADIL data links. Force operations are involved in the support of the operation, providing for the allocation of air defense resources, the assignment of operations and priorities of defended assets, and the coordination and implementation of firing restrictions and rules of engagement. Typically, force operations are non-real-time or near-real-time.
The use of military standards such as MIL-STD-1477B for engagement operations symbology is encouraged, but no symbology standard for engagement operations is mandated by the JTA. The following standard is mandated for the display of common warfighting symbology for force operations:
WS.MS: Missile Systems Subdomain
Subdomain Overview
A weapon system is a combination of one or more weapons with all related equipment, materials, services, personnel and means of delivery and deployment (if applicable) required for self-sufficiency.
Systems covered within the Missile Systems Subdomain include Strategic and Theater Ballistic Missile Systems; Cruise Missile Systems; and rocket and missile systems used in diverse Battlefield Functional Areas including Fire Support, Close Combat, and Special Operations. Note that Missiles which are components of U.S. National and Theater Missile Defense systems are not included in the Missile Systems Subdomain, but instead are covered in the Missile Defense Subdomain. The diversity of missions that missile systems must perform induces a variety of system solutions including shoulder-fired, line-of-sight direct fire, and non-line-of-sight indirect fire missiles and rockets; ground-launched, air-launched, and ship-launched or submarine-launched cruise missiles; surface-to-surface, surface-to-air, ship-to-ship, air-to-air, and air-to-ground missiles; and Inter-Continental, Intermediate Range, and Submarine-Launched Ballistic Missiles (ICBMs, IRBMs, and SLBMs respectively). Broadly, Missile Systems may be described in terms of the following subsystems: 1) missile, 2) launcher, 3) C3I (including fire control or battle management), and, in some cases, 4) sensor. These subsystems are designed and developed to deploy and function as a single Missile System in which all the subsystems are, to a certain degree, interdependent. The Missile System may have all of the subsystems collocated or distributed. For example, a sensing device may be onboard a missile or on the ground, in the air, or in space providing information to the missile via a high-performance data link. Also, a missile's fire control or battle management system may be collocated in the launch vehicle or geographically separate from the launch vehicle, but connected through a direct (physical), line-of-sight, or non-line-of-sight communications link.
Purpose
This subdomain builds on the Weapon Systems Domain by identifying Missile Systems subdomain-specific standards including information standards and analogous standards applicable to Missile Systems. (See See Information Technology Standards for relationships between Core, domain, and subdomain standards.)
Background
The standards in this subdomain are based on the ongoing work of the Joint weapons community.
Subdomain Description
For a description of this subdomain, see See Subdomain Overview. For the purpose of this subdomain, Missile Systems include all offensive missile and rocket systems.
Scope and Applicability
The scope of this subdomain is all DoD Missile Systems (as defined in WS.MS.1 and WS.MS.1.3). However, the standards listed in this version of the subdomain currently address only Army Missile and Rocket Systems. This is a first step in evolving a comprehensive and complete set of standards for Missile Systems for all the Services. It is acknowledged that this evolution will require extensive interaction with many communities to resolve standardization issues.
Technical Reference Model
The Technical Reference Model (TRM) used in this subdomain is the TRM described in the Weapon Systems Domain.
Subdomain Organization
This subdomain is divided into three sections: the Subdomain Overview in WS.MS.1, the Subdomain-Specific Standards in WS.MS.2, and the Subdomain-Specific Service Areas and Interfaces in WS.MS.3. WS.MS.2 follows the JTA Core service area structure. The structure of WS.MS.3 follows the structure of Section 3 of the Weapon Systems Domain.
Additions to JTA Core
Introduction
This section identifies the subdomain-specific mandated and emerging standards for the Missile Systems Subdomain.
Information Processing Standards
Currently, there are no subdomain-specific mandated or emerging standards in this section.
Information Transfer Standards
Currently, there are no subdomain-specific mandated or emerging standards in this section.
Information Modeling, Metadata, and Information Exchange Standards
Currently, there are no subdomain-specific mandated or emerging standards in this section.
Subdomain-Specific Services and Interfaces
Introduction
The Interfaces View of the TRM, depicted in See : DoD Technical Reference Model (DoD TRM), provides sufficient fidelity for identifying classes of interfaces to apply open systems interface standards to the design of real-time and embedded hardware/software systems. The Interface View also facilitates the identification of critical functions and interfaces within the real-time and embedded computing systems of the Missile Systems Subdomain. This section provides a common framework identifying mandated and emerging embedded computing interface standards associated with the logical and direct interface classes defined for the layers depicted in the Interfaces View of the TRM.
Application Software Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards in this section.
System Services Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards in this section.
Resource Access Services Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards in this section.
Physical Resources Layer Interfaces
Emerging Standards
Standards used across multiple Missile Systems and their platforms are expected to see continued use in the development of future Missile Systems and upgrades to existing systems.
The following standard is emerging for applications requiring digital, command/response, time division multiplexing techniques, and defines the data bus line and its interface electronics, the concept of operation and information flow on the multiplex data bus, and the electrical and functional formats to be employed.
The following industrial bus standard is emerging for applications requiring high-speed data transfer, rugged construction, excellent shock and vibration resistance, Plug'n Play capability, and the desire for future hot-swappable support.
The following standard is emerging for applications that require an efficient peer-to-peer I/O bus capable of handling up to 16 devices, including one or more hosts. This standard includes command sets for magnetic and optical disks, tapes, printers, processors, CD-ROMs, scanners, medium changers, and communications devices.
The following standard is emerging for applications requiring hot-swappable peripherals that add memory, mass storage, and I/O capabilities to computers in a rugged, compact form factor.
The following standard is emerging when using a VME bus, an internal interconnect (backplane) bus intended for connecting processing elements to their immediate fundamental resources, and is cited to facilitate mechanical interchangeability of conduction-colled circuit card assemblies in a format suitable for military and rugged applications and to ensure their compatibility with the commercial, double-height 16 mm, Eurocard chassis.
WS.MUS: Munition Systems Subdomain
Subdomain Overview
A weapon system is a combination of one or more weapons with all related equipment, materials, services, personnel, and means of delivery and deployment (if applicable) required for self-sufficiency.
Within DoD's inventory of weapon systems, many systems do not fit within the parameters of the well-defined Weapon Systems Subdomains of Missile Defense Systems, Soldier Systems, Ground Vehicle Systems, or Aviation Systems. These non-mobile, transportable, weapon systems include, but are not limited to, munitions, munitions integrated with sensors, control stations, combat communication systems, repeaters, and gateways. The Munition Systems Subdomain includes any system or subsystem that contains an explosive warhead (such as dumb, smart, and precision bombs, or mines and artillery shells) and that detects, classifies, identifies, intercepts, and destroys or negates the effectiveness of the enemy.
Purpose
This subdomain builds on Weapon Systems Domain by identifying Munition Systems Subdomain-specific standards including information standards and analogous standards applicable to Munition Systems. (See See Information Technology Standards for relationships between Core, domain, and subdomain standards.)
The primary purpose of establishing a subdomain is to ensure interoperability, defined as the ability of two or more systems or components to exchange data and use information (IEEE STD 610.12A-1990) within the family of systems that constitute the subdomain.
This version is focused solely on Landmine Munition Systems, with the intent of expanding this subdomain in the future.
Background
The standards in this subdomain are based on the work performed by the weapons community.
Subdomain Description
Munition Systems included in this subdomain are those whose parameters cannot be accurately described within the parameters of the well-defined Weapon Systems Subdomains of Missile Systems, Soldier Systems, Ground Vehicle Systems, or Aviation Systems. These Munition Systems are primarily unattended and autonomous, with unique environmental and operational mission requirements (e.g., positive systems control and management, long-range remote communications, physical packages and platforms, security and survivability, performance, safety) that are not common to other subdomains. Their system elements may include combinations of autonomous and remotely commanded munitions with or without the following: onboard sensors, networked combat sensors and/or sensor suites, and control stations with integral combat communications, including combat communication systems, information processing gateways, and repeaters.
Scope and Applicability
The scope of this subdomain is the entire Munition Systems Subdomain (as defined in the overview and subdomain description above). However, the standards listed within this version of the subdomain solely address support for Landmine Munition Systems, as a first step in evolving a comprehensive and complete set of standards for Munition Systems. It is acknowledged that this evolution will require interaction with many communities to resolve standardization issues.
Technical Reference Model
The Technical Reference Model used in this subdomain is the Technical Reference Model (TRM) described in the Weapon Systems Domain.
Subdomain Organization
This subdomain is divided into three sections: the Subdomain Overview in WS.MUS.1, the subdomain-specific standards in WS.MUS.2, and the subdomain-specific services and interfaces in WS.MUS.3. WS.MUS.2 follows the JTA Core service area structure. The structure of WS.MUS.3 follows the structure of Weapon Systems Domain WS.3.
Additions to the JTA Core
Introduction
This section identifies the subdomain-specific mandated and emerging standards for the Munition Systems Subdomain.
Information Processing Standards
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Munition Systems Subdomain.
Information Transfer Standards
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Munition Systems Subdomain.
Information Modeling, Metadata, and Information Exchange Standards
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Munition Systems Subdomain.
Subdomain-Specific Services and Interfaces
Introduction
The Interfaces View of the TRM, depicted in See : DoD Technical Reference Model (DoD TRM), provides sufficient fidelity for identifying classes of interfaces to apply open systems interface standards to the design of real-time and embedded-hardware/software systems. The Interface View also facilitates the identification of critical functions and interfaces within the real-time and embedded-computing systems of the Munition Systems.
This section provides a common framework identifying mandated and emerging embedded-computing interface standards associated with the logical and direct interface classes defined for the layers depicted in the TRM.
Only those layers of the TRM that have subdomain-specific mandated or emerging standards identified are addressed in this section.
Application Software Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Munition Systems Subdomain.
System Services Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Munition Systems Subdomain.
Resource Access Services Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Munition Systems Subdomain.
Physical Resources Layer Interfaces
Mandated Standards
The following standard is mandated for applications that require an efficient peer-to-peer I/O bus capable of handling up to 16 devices, including one or more hosts. This standard includes command sets for magnetic and optical disks, tapes, printers, processors, CD-ROMs, scanners, medium changers, and communications devices.
The following industrial bus standard is mandated for applications requiring high-speed data transfer, rugged construction, excellent shock and vibration resistance, Plug'n Play capability, and the desire for future hot-swappable support.
The following standard is mandated for applications requiring hot-swappable peripherals that add memory, mass storage, and I/O capabilities to computers in a rugged, compact form factor.
WS.SS: Soldier Systems Subdomain
Subdomain Overview
A weapon system is a combination of one or more weapons with all related equipment, materials, services, personnel, and means of delivery and deployment (if applicable) required for self-sufficiency.
Systems covered within the Soldier Systems Subdomain include any system or subsystem integrating target location, target identification, target acquisition, enhanced survivability, navigation, position location, enhanced mobility, and command-and-control into a system worn or carried by an individual soldier in performance of assigned duties.
Purpose
This subdomain builds on the Weapon Systems Domain by identifying Soldier Systems Subdomain-specific standards including information standards and analogous standards applicable to Soldier Systems. (See See Information Technology Standards for relationships between JTA Core, domain, and subdomain standards.)
Background
The standards in this subdomain are based on the work performed by the weapons community.
The following documents provide useful background information regarding soldier systems with particular emphasis on fighting systems:
Subdomain Description
The systems of this subdomain integrate weapons, target detection, location and warning sensors, ballistic and environmental protective equipment, positioning and location equipment, helmet-mounted displays, load carrying, sustainment and special-purpose equipment onto the soldier as the platform. The systems are functionally integrated using an embedded computer with multiple pieces of radio communications equipment to enhance command-and-control and combat effectiveness. These capabilities are achieved through integration of Government-Furnished Equipment and the use of commercial-off-the-shelf technologies to meet the key performance parameters of soldier systems. These systems are optimized to minimize the total weight carried by the individual while minimizing the cognitive overload. These systems are required to meet the tactical battlefield environmental characteristics including delivery by parachute while worn by the soldier. All systems are self-contained, man-packed and battery-powered. Systems do not rely on any fixed infrastructure to meet the operational performance requirements.
Scope and Applicability
The scope of this subdomain is the entire Soldier Systems Subdomain as defined in Section WS.SS.1 above.
Subdomain-Specific Standards
Introduction
This section identifies the subdomain-specific mandated and emerging standards for the Soldier Systems Subdomain.
Information Processing Standards
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Soldier Systems Subdomain.
Information Transfer Standards
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Soldier Systems Subdomain.
Information Modeling, Metadata, and Information Exchange Standards
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Soldier Systems Subdomain.
Subdomain-Specific Services and Interfaces
Introduction
The Interfaces View of the TRM, depicted in See : DoD Technical Reference Model (DoD TRM), provides sufficient fidelity for identifying classes of interfaces to apply open systems interface standards to the design of real-time and embedded hardware/software systems. The Interface View also facilitates the identification of critical functions and interfaces within the real-time and embedded-computing systems of the Soldier Systems Subdomain.
This section provides a common framework identifying mandated and emerging embedded-computing interface standards associated with the logical and direct interface classes defined for the layers depicted in the TRM.
Only those layers of the TRM that have subdomain-specific mandated or emerging standards identified are addressed in this section.
Application Software Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Soldier Systems Subdomain.
System Services Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Soldier Systems Subdomain.
Resource Access Services Layer Interfaces
Currently, there are no subdomain-specific mandated or emerging standards identified for this section of the Soldier Systems Subdomain.
Physical Resources Layer Interfaces
Mandated Standards
The unique mission requirements of Soldier Systems dictate system and environmental constraints (e.g., long battery life, low power consumption, small size, light-weight, shock resistant, critical EMI-shielded constraints, all-weather operation, use with NBC protective gear) that make current state-of-the-art digital and/or color video equipment unsuitable for use with Soldier Systems. Therefore, the following standards are mandated for soldier systems employing analog and/or monochrome video technology:
Note: Multiple acronyms are sometimes shown for the same term where the different acronyms are used in the document. For example, the text of the document consistently uses "Mbits/s" for "Megabits per second," but the abbreviation "Mbps" is used in the titles of some standards.
For a list of the mandated and emerging standards in the DoD Joint Technical Architecture, go to DoD Joint Technical Architecture List of Mandated and Emerging Standards at <http://www-jta.itsi.disa.mil> .
Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01A: Compatibility, Interoperability, and Integration of Command, Control, Communications, Computers, and Intelligence Systems, 30 June 1995.
Joint Chiefs of Staff. Joint Vision 2010. Chairman of the Joint Chiefs of Staff, 5126 Joint Staff, Pentagon, Washington, D.C., 20318-5126, June 1997.
Defense Management Report Decision (DMRD) 918: Defense Information Infrastructure, September 15, 1992.
Defense Standardization Program (DSP) 4120.3-M: Policies and Procedures. Office of the Assistant Secretary of Defense, Production and Logistics, July 1993.
Department of Defense Directive 4630.5: Compatibility, Interoperability, and Integration of Command, Control, Communications, and Intelligence (C3I) Systems. November 12, 1992.
Department of Defense Regulation (DoDR) 5000.2-R: Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs, March 15, 1996.
Department of Defense Directive (DoDD) 5000.59: DoD Modeling and Simulation (M&S) Management, January 4, 1994.
Department of Defense 5000.59-P: DoD Modeling and Simulation (M&S) Master Plan (MSMP), October 1995.
IEEE 1232.1:1997, Artificial Intelligence Exchange and Services Tie to All Test Environments (AI-ESTATE): Data and Knowledge Specification.
Information Technology Management Reform Act (ITMRA) (also known as Clinger-Cohen Act of 1996 (Public Law 104-106).
Memorandum: Secretary of Defense: Specifications and Standards - A new Way of Doing Business, June 1994.
Office of Management and Budget Circular No. A-119: Federal Participation in the Development and Use of Voluntary Standards, October 20, 1993.
DOD (Specifications and) Standards Reform Background
The DoD Standards Reform was begun in June 1994 when the Secretary of Defense issued his memorandum entitled "Specifications and Standards - A New Way of Doing Business." The Secretary of Defense directed that performance-based specifications and standards or nationally-recognized private sector standards be used in future acquisitions. The intent of this initiative is to eliminate non-value added requirements, and thus to reduce the cost of weapon systems and materiel; remove impediments to getting commercial state-of-the-art technology into our weapon systems; and integrate the commercial and military industrial bases to the greatest extent possible. The Defense Standards Improvement Council (DSIC) directs implementation of the Reform. The DSIC has interpreted and extended the Reform policy through a series of numbered OSD policy memos. These policy memos and other DSIC decisions, newsletters and other standardization related information are posted on the Defense Standardization Program (DSP) World Wide Web home page at: <http://www.dsp.dla.mil/> .
The JTA and the DoD Standards Reform
The standards and specifications and other standardization documents identified in the Joint Technical Architecture (JTA) can be cited in solicitations without conflicting with the DoD Standards Reform. All JTA standards have been granted Department-wide exemption from the waiver requirement by the Defense Standards Improvement Council. Mandatory application of JTA standards to acquisition solicitations is authorized. Contrary to interpretations that have been made in the recent past by some DoD organizations, the DoD Standards Reform is not eliminating military standards and specifications nor precluding their use. What the Reform is trying to eliminate is the automatic development and imposition of military-unique standards and specifications as the cultural norm. The JTA calls out non-Government standards in every case where it makes sense and where it will lead to the use of commercial products and practices that meet the DoD's needs. The JTA only calls out Military and Federal standards and specifications in those instances where no non-Government standard exists that is cost effective and meets the requirement or where the use of the non-Government standard must be clarified to enable interoperability of DoD systems.
Reform Waiver Policy
Policy Memo 95-1 establishes procedures for waivers for use of specifications and standards cited as requirements in solicitations. These waiver procedures apply to the types of standards that fall under the province of the Defense Standardization Program and are indexed in the DoD Index of Standards and Specifications (DoDISS). Specifically of relevance to the JTA, Policy Memo 95-1 states that non-Government standards, Interface Standards, Federal Information Processing Standards (FIPS), and Performance Specifications do not require waivers. Also, Policy Memo 95-9 provides that international standardization agreements such as NATO STANAGs (and ACPs) do not require waivers. Federal Telecommunications Standards (FED-STD) do not require a waiver when they qualify as interface standards. All of the above waiver-free document types encompass most of the standards cited in the JTA. The DSP Home Page provides lists of waiver-free standards and in the near future the DoDISS will indicate those standards that can be used without a waiver.
Non-DoDISS Standards Not Subject to the Reform Waiver Policy
There are a small number of JTA standards that are not among the types of Government standards that are indexed in the DoDISS and are therefore not subject to the Reform waiver policy. Therefore, they also do not require a waiver to be cited in a solicitation. However, the citation of these non-DoDISS standards in solicitations must comply with Service/Agency requirements for preparation and approval of performance-based program unique specifications. A system specification used to procure a C4I system or a weapon system is a program unique specification. Procedures for preparing performance specifications are provided in MIL-STD-961D, Defense Specifications, Change 1, 22 August 1995 and in the DSP Performance Specification Guide, SD-15, dated 29 June 1995. MIL-STD-961D defines a performance specification as follows: "A specification that states requirements in terms of the required results with criteria for verifying compliance, but without stating the methods for achieving the required results. A performance specification defines the functional requirements for the item, the environment in which it must operate, and interface and interchangeability characteristics." By this definition, standards that define "interface" characteristics can be properly cited in a performance specification. Therefore, JTA non-DoDISS standards that are used to define interface characteristics are not in conflict with service/agency requirements for preparation and approval of performance-based program unique specifications.
Interface Standards Are Waiver-Free
Most JTA standards qualify as Interface Standards. Policy Memo 95-6 defines the five types of DoD-prepared standards as: interface standards, standard practices, test method standards, manufacturing process standards, and design criteria standards. Policy Memo 95-1 states that of these types, interface standards and standard practices do not require a waiver when cited in a solicitation. MIL-STD-962C (a standard practice) provides definitions, format, and content direction for military standards. It defines an interface standard as follows: "A standard that specifies the physical, functional, or military operational environment interface characteristics of systems, subsystems, equipment, assemblies, components, items or parts to permit interchangeability, interconnection, interoperability, compatibility, or communications." The use of military and Federal interface standards in solicitations is fully compliant with the DoD Standards Reform.
Non-Government Standards Vs. Military/Federal Standardization Documents
One of DoD's key acquisition reform goals is to reduce acquisition costs and remove impediments to commercial-military integration by emulating commercial buying practices wherever possible. Thus, for any processes, practices, or methods that are described by a non-Government standard used by Commercial firms and which meet DoD's needs, DoD activities should also be using a non-Government standard instead of applying, developing, or revising a military or Federal Standard. The standards selected for the JTA are predominantly non-Government standards. Military or Federal standards have been selected for the JTA only in those instances where non-Government standards failed to satisfy the DoD needs. In most of those instances, in fact, the military or Federal standard is a profile of one or more non-Government standards. The military or Federal profile identifies the chosen classes, subsets, options, and parameters of one or more base standards necessary for achieving interoperability (or other function). In some instances, the profile specifies unique interface requirements not satisfied by the non-Government standard. Therefore the JTA complies fully with this key acquisition reform goal.
Note: Where two textual variants of the same term, e.g., "real time" and "real-time" occur in the document, both are shown.
Accreditation
The managerial authorization and approval granted to an ADP system or network to process sensitive data in an operational environment, made on the basis of a certification by designated technical personnel of the extent to which design and implementation of the system meet pre-specified technical requirements, e.g., TCSEC, for achieving adequate data security. Management can accredit a system to operate at a higher/lower level than the risk level recommended (e.g., by the Requirements Guideline) for the certification level of the system. If management accredits the system to operate at a higher level than is appropriate for the certification level, management is accepting the additional risk incurred.
Activity Model (IDEF0)
A graphic description of a system or subject that is developed for a specific purpose and from a selected viewpoint. A set of one or more IDEF0 diagrams that depict the functions of a system or subject area with graphics, text and glossary. (FIPS Pub 183, Integration Definition For Function Modeling (IDEF0), December 1993)
Aggregate-Level Simulation Protocol (ALSP)
A family of simulation interface protocols and supporting infrastructure software that permit the integration of distinct simulations and war games. Combined, the interface protocols and software enable large-scale, distributed simulations and war games of different domains to interact at the combat object and event level. The most widely known example of an ALSP confederation is the Joint/Service Training Confederation (CBS, AWSIM, JECEWSI, RESA, MTWS, TACSIM, CSSTSS) that has provided the backbone to many large, distributed, simulation-supported exercises. Other examples of ALSP confederations include confederations of analytical models that have been formed to support U.S. Air Force, U.S. Army, and U.S. TRANSCOM studies. (DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995, authorized by DoD Directive 5000.59, January 4, 1994)
Application Platform
The collection of hardware and software components that provide the services used by support and mission-specific software applications. (DoD TRM, Version 1.0, 5 November 1999)
The application platform is defined as the set of resources that support the services on which application software will execute. It provides services at its interfaces that, as much as possible, make the implementation-specific characteristics of the platform transparent to the application software. (DoD TRM, Version 1.0, 5 November 1999)
Application Software Entity
Mission-area and support applications. A common set of support applications forms the basis for the development of mission-area applications. Mission-area applications should be designed and developed to access this set of common support applications. Applications access the Application Platform via a standard set of APIs. (DoD TRM, Version 1.0, 5 November 1999)
Architecture
Architecture has various meanings, depending upon its contextual usage. (1) The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. (2) Organizational structure of a system or component. (IEEE STD 610.12-1990; DoD TRM, Version 1.0, 5 November 1999) or;
An architecture is a composition of (1) components (including humans) with their functionality defined (Technical), (2) requirements that have been configured to achieve a prescribed purpose or mission (Operational), and (3) their connectivity with the information flow defined. (OSJTF)
Combatant Command
A unified or specified command with a broad continuing mission under a single commander [Commander-in-Chief, CINC] established and so designated by the President, through the Secretary of Defense with the advice and assistance of the Chairman of the Joint Chiefs of Staff. Combatant commands typically have geographic [e.g., Middle East, Central Command] or functional [e.g., military equipment and personnel transport, Transportation Command] responsibilities. [Source--Joint Pub 1-02, 10 June 1998]
Unless otherwise directed by the President or Secretary of Defense, the authority, direction, and control of the Commander of a Unified or Specified Combatant Command with respect to all the commands and forces assigned to that command [including Headquarters, Service, and Agency Components] include the command functions of giving authoritative direction to subordinate commands and forces necessary to carry out missions assigned to the command... [Source: DoD Directive 5100.1, "Functions of the Department of Defense and Its Major Commands," September 25, 1987].
Command and Control
The exercise of authority and direction by a properly designated commander over assigned and attached forces in the accomplishment of the mission. Command and control functions are performed through an arrangement of personnel, equipment, communications, facilities, and procedures employed by a commander in planning, directing, coordinating, and controlling forces and operations in the accomplishment of the mission. (Joint Pub 1-02)
Commercial Item
Any item customarily used by the general public for other than governmental purposes, that has been sold, leased, or licensed to the general public, or that has been offered for sale, lease, or license to the general public.
Any item that evolved from an item described above through advances in technology or performance that is not yet available in the commercial market, but will be available in time to meet the delivery requirements of the solicitation.
Any item that, but for modifications of a type customarily available in the commercial market or minor modifications made to meet DoD requirements, would satisfy the criteria above.
Any combination of items meeting the requirements above or below that are of a type customarily combined and sold in combination to the general public.
Installation services, maintenance services, repair services, training services, and other services if such services are procured for support of any item referred to above, if the sources of such services:
Services offered and sold competitively, in substantial quantities, in the commercial marketplace based on established catalog prices of specific tasks performed and under standard commercial terms and conditions.
(Standardization Document [SD-2], Buying Commercial and Nondevelopmental Items: A Handbook. Office of the Under Secretary of Defense for Acquisition and Technology, April 1996.)
Commercial off-the-Shelf (COTS)
Refers to an item of hardware or software that has been produced by a contractor and is available for general purchase. Such items are at the unit level or higher. Such items must have been sold and delivered to government or commercial customers, must have passed customer's acceptance testing, be operating under customer's control, and within the user environment. Further, such items must have meaningful reliability, maintainability, and logistics historical data. (DoD TRM, Version 1.0, 5 November 1999)
Conceptual Model of the Mission Space (CMMS)
One of the three components of the DoD Common Technical Framework (CTF). They are first abstractions of the real world and serve as a frame of reference for simulation development by capturing the basic information about important entities involved in any mission and their key actions and interactions. They are simulation-neutral views of those entities, actions, and interactions occurring in the real world. (DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995, authorized by DoD Directive 5000.59, January 4, 1994)
Confidentiality
Configuration Management
A discipline applying technical and administrative direction and surveillance to: (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to those characteristics, and (3) record and report changes to processing and implementation status. (DoD TRM, Version 1.0, 5 November 1999)
Data Dictionary
A specialized type of database containing metadata that is managed by a data dictionary system; a repository of information describing the characteristics of data used to design, monitor, document, protect, and control data in information systems and databases; an application of a data dictionary system. (DoD 8320.1-M-1, "Data Element Standardization Procedures," January 15, 1993, authorized by DoD Directive 8320.1, September 26, 1991)
Data Model
In a database, the user's logical view of the data in contrast to the physically stored data, or storage structure. A description of the organization of data in a manner that reflects the information structure of an enterprise. (DoD 8320.1-M-1, "Data Element Standardization Procedures," January 15, 1993, authorized by DoD Directive 8320.1, September 26, 1991)
Distributed Interactive Simulation (DIS)
Program to electronically link organizations operating in the four domains: advanced concepts and requirements; military operations; research, development, and acquisition; and training. A synthetic environment within which humans may interact through simulation(s) at multiple sites networked using compliant architecture, modeling, protocols, standards, and databases. (DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995, authorized by DoD Directive 5000.59, January 4, 1994)
Element
A service area, interface, or standard within the JTA document. The definitions below are abbreviated versions of those appearing elsewhere in the JTA Glossary.
Electronic Business/Electronic Commerce
The interchange and processing of information via electronic techniques for accomplishing transactions based upon the application of commercial standards and practices. An integral part of implementing EB/EC is the application of business process improvement or reengineering to streamline business processes prior to the incorporation of technologies facilitating the electronic exchange of business information.
Federation Object Model (FOM)
An identification of the essential classes of objects, object attributes, and object interactions that are supported by an HLA federation. In addition, optional classes of additional information may also be specified to achieve a more complete description of the federation structure and/or behavior. See HLA Glossary: <http://www.dmso.mil> .
Information Technology (IT)
The term "information technology," with respect to an executive agency means any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency that (i) requires the use of such equipment, or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product.
Intelligence
International Electrotechnical Commission (IEC)
An international standards body similar to ISO, but limited by its charter to standards in the electrical and electrotechnical areas. In 1987, the ISO and IEC merged ISO Technical Committee 97 and IEC Technical Committees 47B and 83 to form ISO/IEC Joint Technical Committee (JTC) 1, which is the only internationally recognized committee dealing exclusively with information technology standards.
International Organization for Standardization (ISO)
The International Organization for Standardization (ISO) is a worldwide federation of national standards bodies from some 100 countries, one from each country. ISO is a non-governmental organization, established to promote the development of standardization and related activities in the world with a view to facilitating the international exchange of goods and services, and to developing cooperation in the spheres of intellectual, scientific, technological, and economic activity. ISO's work results in international agreements, which are published as International Standards.
International Telecommunications Union - Telecommunications Standardization Sector (ITU-T)
ITU-T, formerly called the Comité Consultatif International de Télégraphique et Téléphonique (CCITT), is part of the International Telecommunications Union, a United Nations treaty organization. Membership and participation in ITU-T is open to private companies; scientific and trade associations; and postal, telephone, and telegraph administrations. Scientific and industrial organizations can participate as observers. The U.S. representative to ITU-T is provided by the Department of State. Since ITU-T does not have the authority of a standards body nor the authority to prescribe implementation of the documents it produces, its documents are called recommendations rather than standards.
Internet Engineering Task Force (IETF)
The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security). The IETF is a subdivision of the Internet Architecture Board (IAB) responsible for the development of protocols, their implementations, and standardization.
Joint Task Force
A joint force that is constituted and so designated by the Secretary of Defense, a combatant commander, a subunified commander, or an existing joint task force commander. Also called JTF. [Source--Joint Pub 1-02, 10 June 1998] [The JTF includes a Headquarters element and all of the Service Expeditionary Forces that support the Joint Task Force mission.]
Legacy Environments
Legacy environments could be called legacy architectures or infrastructures and as a minimum consist of a hardware platform and an operating system. Legacy environments are identified for phase-out, upgrade, or replacement. All data and applications software that operate in a legacy environment must be categorized for phase-out, upgrade, or replacement. (DoD TRM, Version 1.0, 5 November 1999)
Legacy Standard
A JTA standard that is a candidate for phase-out, upgrade, or replacement. A legacy standard may be an obsolete standard without an upgrade path, or an older version of a currently mandated JTA standard. A legacy standard is generally associated with an existing or "legacy system," although it may be necessary in a new or upgraded system when an interface to a legacy system is required. (JTADG)
Legacy Systems
Systems that are candidates for phase-out, upgrade, or replacement. Generally legacy systems are in this category because they do not comply with data standards or other standards. Legacy system workloads must be converted, transitioned, or phased out (eliminated). Such systems may or may not operate in a legacy environment. (DoD TRM, Version 1.0, 5 November 1999)
Live, Virtual, and Constructive Simulation
The categorization of simulation into live, virtual, and constructive is problematic because there is no clear division between these categories. The degree of human participation in the simulation is infinitely variable, as is the degree of equipment realism. This categorization of simulations also suffers by excluding a category for simulated people working real equipment (e.g., smart vehicles). (DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995, authorized by DoD Directive 5000.59, January 4, 1994)
Virtual Simulation . A simulation involving real people operating simulated systems. Virtual simulations inject human-in-the-loop (HITL) in a central role by exercising motor control skills (e.g., flying an airplane), decision skills (e.g., committing fire control resources to action), or communication skills (e.g., as members of a C4I team)
Model
A physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process. ("A Glossary of Modeling and Simulation Terms for Distributed Interactive Simulation (DIS)," August, (DoD Directive 5000.59, "DoD Modeling and Simulation (M&S) Management," January 4, 1994); (DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995, authorized by DoD Directive 5000.59, January 4, 1994).
Modeling and Simulation (M&S)
The use of models, including emulators, prototypes, simulators, and stimulators, either statically or over time, to develop data as a basis for making managerial or technical decisions. The terms "modeling" and "simulation" are often used interchangeably. ("M&S Educational Training Tool (MSETT), Navy Air Weapons Center Training Systems Division Glossary," April 28, 1994)
National Institute of Standards and Technology (NIST)
The division of the U.S. Department of Commerce that ensures standardization within Government agencies. NIST was formerly known as the National Bureau of Standards. NIST develops and maintains Federal Information Processing Standards (FIPS) PUBS, the standards the Federal Government uses in its procurement efforts. Federal agencies, including DoD, must use these standards where applicable.
National Security System
The term "national security system" means any telecommunications or information system operated by the United States Government, the function, operation, or use of which: (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) subject to subsection (b), is critical to the direct fulfillment of military or intelligence missions.
Nondevelopmental Item (NDI)
Any previously developed item used exclusively for governmental purposes by a U.S. Federal, State or Local government agency or a foreign government with which the U.S. has a mutual defense cooperation agreement.
Open System
A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be utilized across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems, and to interact with users in a style that facilitates portability. An open system is characterized by the following:
(IEEE POSIX 1003.0/D15 as modified by the Tri-Service Open Systems Architecture Working Group)
Open Systems Approach
An open systems approach is a business approach that emphasizes commercially supported practices, products, specifications, and standards. The approach defines, documents, and maintains a system technical architecture that depicts the lowest level of system configuration control. This architecture clearly identifies all the performance characteristics of the system including those that will be accomplished with an implementation that references open standards and specifications. (OSJTF)
Operational Architecture (OA)
An Operational Architecture is a description (often graphical) of the operational elements, assigned tasks, and information flows required to support the warfighter. It defines the type of information, the frequency of the exchange, and what tasks are supported by these information exchanges. (JTA 1.0)
Real Time, also Real-Time
Reference Model
A reference model is a generally accepted abstract representation that allows users to focus on establishing definitions, building common understandings, and identifying issues for resolution. For Warfare and Warfare Support System (WWSS) acquisitions, a reference model is necessary to establish a context for understanding how the disparate technologies and standards required to implement WWSS relate to each other. Reference models provide a mechanism for identifying key issues associated with portability, scalability, and interoperability. Most importantly, reference models will aid in the evaluation and analysis of domain-specific architectures. (TRI-SERVICE Open Systems Architecture Working Group)
Security
The quality or state of being protected from uncontrolled losses or effects. Note: Absolute security may in practice be impossible to reach; thus the security "quality" could be relative. Within state models of security systems, security is a specific "state" that is to be preserved under various operations.
Simulation Object Model (SOM)
A specification of the intrinsic capabilities that an individual simulation offers to federations. The standard format in which SOMs are expressed provides a means for federation developers to quickly determine the suitability of simulation systems to assume specific roles within a federation. See HLA Glossary: <http://www.dmso.mil> .
Synthetic Environments (SE)
Interneted simulations that represent activities at a high level of realism from simulations of theaters of war to factories and manufacturing processes. These environments may be created within a single computer or a vast distributed network connected by local and wide area networks and augmented by super-realistic special effects and accurate behavioral models. They allow visualization of and immersion into the environment being simulated. (DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995, authorized by DoD Directive 5000.59, January 4, 1994); (CJCSI 8510.01, Chairman of the Joint Chiefs of Staff Instruction 8510.01, "Joint Modeling and Simulation Management," February 17, 1995)
Systems Architecture (SA)
A description, including graphics, of the systems and interconnections providing for or supporting a warfighting function. The SA defines the physical connection, location, and identification of the key nodes, circuits, networks, warfighting platforms, etc., and allocates system and component performance parameters. It is constructed to satisfy Operational Architecture requirements in the standards defined in the Technical Architecture. The SA shows how multiple systems within a domain or an operational scenario link and interoperate, and may describe the internal construction or operations of particular systems in the SA.
Technical Architecture (TA)
The minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements whose purpose is to ensure that a conformant system satisfies a specified set of requirements. The technical architecture identifies the services, interfaces, standards, and their relationships. It provides the technical guidelines for implementation of systems upon which engineering specifications are based, common building blocks are built, and product lines are developed.
Technical Reference Model (TRM)
A conceptual framework that provides the following:
A consistent set of service and interface categories and relationships used to address interoperability and open system issues.
Conceptual entities that establish a common vocabulary to better describe, compare, and contrast systems and components.
1. These definitions are extracted from the C4ISR Architecture Framework 2.0. The definitions and the products required by the framework focus on information technology. However, the concepts described can be applied to a wide range of technologies.
2. Additional guidance may be found in the memorandum "Use of the Ada Programming Language" by ASD (C3I), April 29, 1997, DoD 5000.2-R, and DoDD 3405.1.
3. Cryptologic Community defines entities composed of the NSA, elements of the military departments and the CIA performing SIGINT activities, and elements of an other department or agency of the Federal Government that may, from time to time, be so authorized, and the Information Systems Security activities that protect these SIGINT activities. SIGINT is defined as intelligence information comprising, either individually or in combination, all communications intelligence, electronics intelligence, and foreign instrumentation signals intelligence, however transmitted.
4. Institute for Defense Analysis (IDA) Investment Strategy Study. Alexandria, VA: Institute for Defense Analysis (IDA), 1993.
5. Joint Pub 1-02, DoD Dictionary of Military and Associated Terms, 23 March 1994, as Amended through 1 September 2000.
6. Missile defense can be viewed as having four pillars: active defense, attack operations, passive defense, and an overarching BMC4I. In this context, active defense is direct defensive action taken to nullify or reduce the effectiveness of hostile air action, such as the use of missile defense weapons. Attack operations includes activities such as directly attacking missile launchers. Passive defense is all other measures taken to minimize the effectiveness of a specific hostile air action, including deception and dispersion. The overarching BMC4I directs and coordinates all these activities.