Army Digitization Master Plan '96
4. ARCHITECTURE
4.1 DoD Architecture Initiatives
There are several DoD initiatives that have a direct impact on the architectures being developed for Army digitization and on the ADMP.
4.1.1 Technical Architecture Framework for Information Management (TAFIM)
The Technical Reference Model (TRM) for Information Management was the initial effort to bring commonality and standardization to DoD's technical infrastructure. Although the TRM addressed the services and standards required to implement a common technical infrastructure, a single TA framework was still needed to integrate these efforts and drive systems design, acquisition, and software re–use throughout DoD.
TAFIM was developed to meet that requirement. It provides the DoD-wide framework to manage multiple TA initiatives and is intended to achieve the following results:
TAFIM does not provide a specific architecture. It provides the services, standards, design concepts, components and configurations used to guide development of TAs meeting specific mission requirements. TAFIM is independent of mission-specific applications and their associated data. System architects and designers will use TAFIM as the basis for developing a common target architecture to which systems can migrate, evolve, and interoperate.
Proper application of the TAFIM guidance will:
TAFIM introduces and promotes interoperability, portability, and scalability of DoD information systems. Over time, the number of compliant systems will increase, providing users with improved interoperability needed to achieve common functional objectives. To achieve portability, standard interfaces will be developed and implemented. Scalability will be developed in mission applications to accommodate functional flexibility.
4.1.2 DoD Open Systems Policy
4.1.2.1 Open Systems Standards
In a policy memorandum dated 29 June 1994, the Secretary of Defense stated his commitment to “a new way of doing business” in DoD, to include the use of open systems (consensus-based, public, or non-proprietary) specifications and standards. To this end, his memorandum directed that the preference for use of specifications and standards within DoD systems acquisitions be performance, commercial, and military, in that order. It further stated that requests to use other than open systems standards would require a waiver.
Based on that policy guidance, the ATA is heavily oriented toward the use of open systems standards. For example, the architecture for the Army Tactical Internet—the key communications component of the Army’s Force XXI initiative—is based on the architecture and open system standards being used by the world-wide Internet.
4.1.2.2 Open Systems Joint Task Force
In a subsequent memorandum dated 29 November 1994, the Undersecretary of Defense for Acquisition and Technology directed that open systems specifications and standards be used for acquisition of weapons systems electronics to the greatest extent practical. He established a joint oversight office—the Open Systems Joint Task Force (OS-JTF)—to ensure implementation of this policy. As amplified in the OS-JTF Charter, the focus of this group is on the acquisition of new systems and system upgrades to electronics embedded in weapons systems and platforms. It is not oriented on C3I systems, communications networks, or real-time data processing functions.
Previous versions of the ATA focused mainly on systems and communications networks used to support C3I activities in the tactical environment. In response to the Undersecretary’s guidance, the Army is addressing embedded electronics in the most recent version of the ATA (see Section 4.2.2.1.5, Planned Enhancements to the Technical Architecture).
4.1.3 Common Operating Environment (COE)
4.1.3.1 Global Command and Control System (GCCS)
GCCS has been designated the single command and control system for DoD. GCCS improves the joint warfighter's ability to manage and execute crisis and contingency operations. It provides a means to interface with joint, Service-specific, and Federal agency C4I systems for peacetime deliberate planning, as well as crisis planning and execution. (see section 5.1, Army GCCS)
The need for GCCS stems from lessons learned from previous conflicts, current/projected operational requirements, and the effects of rapidly changing technology. The warfighter requires a seamless information system, in which boundaries between functions and sources are erased. GCCS provides seamless, integrated information to the warfighter when, where, and how it is needed. The goals of GCCS are:
The COE is an outgrowth of the GCCS effort to achieve the latter goal.
4.1.3.2 COE Development
The development of the current DII COE stems from the GCCS COE effort, and is perhaps the most significant and useful technical by-product of the GCCS development effort. The initial impetus behind GCCS was the replacement of the World Wide Military Command and Control System (WWMCCS), with additional goals of improving C2 interoperability and reducing duplicative C2 system developments. Services and agencies nominated products for incorporation into a COE focused on supporting the WWMCCS replacement. A number were used to create the initial versions of the COE, with the remaining products to be incorporated into later versions of the COE as it expanded to support other systems.
As an outgrowth of this effort, the Services and agencies have agreed to migrate their C2 systems to the DII COE, having independently arrived at similar conclusions. The COE is in reality very simple and straightforward, but powerful in its ability to tailor a system to meet individual site and operator requirements, while retaining the architectural freedom to evolve.
4.1.3.2.1 Fundamental COE Concepts
In COE-based systems, all infrastructure and mission application software—except the operating system and basic windowing software—is packaged in self-contained units called segments. Segments are the most basic building blocks from which a COE-based system can be built and are defined in terms of the functionality they provide. The principles which govern how segments are loaded, removed, or interact with one another are the same for all segments, but COE component segments—which are part of the COE—are treated more strictly because they are the foundation on which the entire system rests. Only the segments required to meet a specific mission application need to be present, allowing a minimization of hardware and software resources required to support a COE-based system.
The terms interoperability and integration are tightly defined in the context of the DII COE. Interoperability refers to the ability for two systems to exchange data unambiguously; with no loss of precision; in a format understood by both systems; and in such a way that interpretation of the identical data is precisely the same. Integration refers to combining segments—not systems—and ensuring that the segments work correctly within the COE environment; do not adversely impact one another; and conform to COE standards. Integration does not imply interoperability. It only provides a level of assurance that the system will work as designed.
4.1.3.2.2 DII COE Integration and Runtime Specification (I&RTS)
The latest I&RTS, dated 23 October 1995, divides the COE into a series of segments, with agencies assigned responsibility for each. Figure 4-1 depicts this schematic, while also identifying the kernel COE components, which are the minimal set of software required on every COE workstation.
Figure 4-1 Defense Information Infrastructure Common Operating Environment (DII COE)
The DII COE I&RTS provides substantive COE guidance to PMs and developers, while also providing DISA with a means to check COE compliance. It includes the process of registering a mission application with the DII PMO, how to segment mission applications for interoperability with other DII-approved applications, and how to manage the DII environment. As a first step to C4I for the Warrior (C4IFTW) and COE compliance, PMs should register their mission applications with GCCS. DISA will issue the developer a unique root directory name under the overall GCCS directory structure. This will guarantee C4IFTW-type capability in that any mission application can be loaded on any authorized GCCS device worldwide. The next step is segmenting and testing the software to ensure peaceful coexistence with all other GCCS-registered mission applications. This entire process is described in the DII COE I&RTS, which is accessible via the World Wide Web at http://164.117.208.50.
4.1.3.3 COE Compliance
The current Defense Planning Guidance for FY1997 to FY2001 mandates the use of the COE as the target system for all DoD systems. The COE is an integral part of the ATA, and the AAE has mandated that implementation plans for compliance with the ATA and migration to the COE must be submitted for all systems.
At present, the GCCS COE is mandated by the ATA. However, GCCS is transitioning to the broader umbrella of the DII, and the Army is committed to mandating the DII COE and its associated Applications Programming Interfaces (APIs) as they evolve. Version 1.0 of the DII COE was released in February 1996, and the DII COE System Engineer has indicated that mission application developers should now be targeting migration of applications to the DII COE instead of the GCCS COE. As such, the Army intends to focus on DII COE compliance, and plans to use the specific criteria provided in DII COE I&RTS Section 2.1.3 for evaluating compliance.
4.1.4 Other Architecture-Related Initiatives
Although not architecture initiatives by definition, there are a number of recently promulgated DoD policies that have a significant impact on Service/agency architectures. The most noteworthy are the policies associated with the Defense Message System, Tactical Data Link Standard, and Data Element Standardization.
4.1.4.1 Defense Message System (DMS)
In a series of policy memoranda, the Assistant Secretary of Defense for C3I (ASD(C3I)) stated that DMS would be the single messaging system for all DoD fixed, mobile, strategic, and tactical environments. The policy dictates that all DoD electronic messaging (i.e., AUTODIN and legacy electronic mail) must migrate to DMS-compliant messaging as rapidly as possible.
Architecturally, DMS is based on the International Telecommunications Union (ITU) X.400 series of recommendations, with extensions to meet U.S. security requirements. Because of these security requirements, a directory service based on the ITU X.500 series of recommendations is required for DMS operation. However, the X.500 directory service has architectural implications that extend beyond mail and messaging to encompass other functions, such as security and file transfer services.
The Army has incorporated DMS-compliant X.400 and X.500 standards into its ATA. An Army DMS Transition Plan has been submitted to DISA's DMS PMO showing how and when DMS components and services will be phased into the Army. Planning is underway for necessary changes to organizations, procedures, and training, and for the acquisition and/or modification of equipment required to implement the plan. AUTODIN replacement is the Army's first priority.
In the first implementation phase, the Army plans to provide DMS messaging and electronic mail capability to all current strategic and tactical AUTODIN users down to maneuver brigade level. In succeeding phases, additional users (e.g., current e–mail users without AUTODIN access) will be provided with a DMS capability.
4.1.4.2 Tactical Data Link Standard
In October 1994, ASD(C3I) published a policy memorandum designating Link 16 as the DoD primary data link for processed information for C2I applications and—where practical—weapons systems, unless an exception is granted by ASD(C3I).
A Joint Tactical Data Link Working Group (TDLWG) was established to prepare a management plan and listing of data links or systems covered by the policy, along with a coordinated migration plan and legacy data link support strategy. For the purposes of the management and migration plans, the TDLWG agreed that Link 16 is the J-Series Family, consisting of F-series (i.e., North Atlantic Treaty Organization (NATO) Link 22), J-Series (i.e., Joint Tactical Information Distribution System (JTIDS)), and K-Series (i.e., VMF), together with the related information transfer standards (e.g., Military Standard (MIL-STD) 188-220A for VMF).
VMF messages intended for use on the Army Tactical Internet were derived from the TADIL J/Link 16 and other jointly agreed data elements. However, addressing and naming conventions are very different and user-transparent gateways and/or dual language hosts will be needed to allow interoperability. The Army will ensure that Link 16 messages and data elements are used to the maximum extent possible, and will work with DoD and the other Services toward an architectural goal of consolidating Link 16 and Army/Joint VMF messaging at some future date. Section 4.2.2.1.3 (Information Modeling and Data Exchange Standards) provides additional information.
4.1.4.3 Data Element Standardization
The ASD(C3I) data element standardization policy states that the Defense Data Dictionary System (DDDS) is the DoD-wide integration point for standard data element definitions. This policy requires the Services, agencies, and unified commands to document the data elements used by their automation processes and to submit them to the DDDS for standardization.
In compliance, the Army has incorporated two IDEF method models into its ATA (IDEF0 process model and IDEF1X data model). This provides both technical guidance and the mechanism by which developers can document data and submit the associated data elements to the DDDS for standardization. See Section 4.2.2.1.3 (Information Modeling and Data Exchange Standards).
4.2 Army Architecture Strategy
To achieve the vision and goals of Force XXI, all battle command systems must be flexible and interoperable. The battle command information infrastructure must support the ability to structure a force rapidly and efficiently to meet any future contingency. Given the split-based operations requirements of a force projection Army, interoperability and flexibility are necessary between tactical systems and the post, camp, and station information systems. Moreover, the need for interoperability and connectivity of battle command systems is not just an intra-Army issue. The need to conduct joint and multinational operations requires open, flexible, and interoperable information infrastructures and the ability to facilitate STOW training.
In 1994, the Army Science Board (ASB) presented the results of its study on a technical (information) architecture for C4I systems. In its final report, the ASB defined technical architecture, differentiated it from operational and system architectures, and recommended a process and organizational structure for developing and enforcing an Army-wide technical architecture. The Army has implemented the ASB's recommendations.
4.2.1 Operational Architecture (OA)
An operational architecture is a description—often graphical—which defines the force elements and the requirement to exchange information between these force elements. It defines the types of information, the frequency of information exchange, and which warfighting tasks are supported by these exchanges. It also specifies what the information systems are operationally required to do and where these operations are to be performed.
The Force XXI OA is being developed by the TRADOC Combined Arms Center, with technical support from PEO C3S. It will provide a detailed breakout of functions, processes, and information flows, and will be developed over an extended period of time in an evolutionary process. In the near–term, the OA for TF XXI will serve as a proof–of–principle for expanded, follow-on versions. It is being developed in two phases:
Development and analysis of the OA will use modeling tools, logical connectivity diagrams, value–added methodologies, assessments of battlefield return–on–investment, and database development.
Development of operational architectures for the Army will be executed in a spiral development process. The start point is TF XXI, with multi-echelon brigade and division development now occurring simultaneously. New operational architectures will be developed as proposed force structures for Force XXI are constructed, modeled, and evaluated.
4.2.2 Technical Architecture (TA)
A technical architecture is the minimal set of rules governing the arrangement, interaction, and interdependence of parts or elements that together may be used to form an information system.
Figure 4-2 Technical Architecture
Its purpose is to ensure that a conformant system satisfies a specified set of requirements. It is the building code for the system architecture being constructed to satisfy operational architecture requirements. Standards laid out in a technical architecture establish the framework for achieving interoperability and commonality among component hardware/software and attaining seamless connectivity between communications systems operating in a digital battlespace.
4.2.2.1 Army Technical Architecture (ATA)
The ATA is an open systems architecture that is compliant with DoD standards and makes maximum use of commercial standards, consistent with mission requirements. Where commercial standards prove inadequate, efforts have been initiated to incorporate required military features into the system and—if possible—into the commercial standards. The architecture was developed in collaboration with the ARSTAF, ASB, ASEO, MACOMs, and PEOs/PMs, based on two primary sources:
ATA Version 4.0 was approved by the VCSA and AAE on 30 January 1996. Each Army Milestone Decision Authority (MDA), MACOM, PEO, PM, ATD Manager, and ACTD Manager is responsible for ATA compliance for all Army systems that electronically produce, use, or exchange information. Specific migration schedules will be integrated with programmed system upgrade windows.
The ATA groups Army systems into the following categories or domains:
ATA Version 4.0 addresses five major topics:
The ATA takes advantage of commercial investment in information technologies. It will not remain static, but will evolve through participation with DoD, industry, and international standards organizations in order to identify emerging trends and standards.
4.2.2.1.1 Information Processing Standards
Within the ATA, information processing standards identify a suite of commercial and government standards and associated implementation profiles that are consistent with the TAFIM TRM and standards profile. Compliance with a standard information processing profile promotes development of integrated applications that share functions and data.
As discussed in 4.1.3.2, a COE is the set of integrated support services supporting mission application software requirements. It also provides a corresponding software development environment, architecture principles, and methodologies which assist in the development of mission application software by capitalizing on infrastructure support services.
The Army is committed to using the DII COE. Where necessary, the Army will extend the COE to fulfill specific support requirements for battlespace command and control systems, and will provide those COE extensions to other Services and the DII PMO.
One of the fundamental concepts of the COE is that shared services will be available to other mission applications through standard APIs (See Figure 4-1). These shared services comprise the COE. Interfaces will be designed and documented so they are easy for developers to understand and use. APIs will be baselined and changed only when with the agreement of the affected parties, using a formal configuration management procedure.
4.2.2.1.2 Information Transport Standards
Within the ATA, information transport standards define the communications support required to provide seamless, reliable, and timely information exchange between users. Communications systems and related network interfaces define the topology of the system, and common protocols provide the means necessary for seamless information exchange between users.
Within the ATA, information transport standards are primarily focused on protocols and profiles for packet data exchange. They are grouped as follows:
The common thread in Army digital data communications will be use of the Internet protocol suite (e.g., TCP/User Datagram Protocol (TCP/UDP) and IP). In Army data communications networks, unique protocols will continue to exist due to military-unique communications requirements. Most notable is MIL-STD 188-220A, a suite of protocols used with Combat Net Radio (CNR) systems, such as SINCGARS.
4.2.2.1.3 Information Modeling and Data Exchange Standards
Within the ATA, information modeling and data exchange standards pertain to process models, data models, data definitions, and data exchanges. They provide the basis for information-sharing across boundaries. Without such standards, it would be necessary to build and maintain individual interfaces, a costly alternative often resulting in inconsistent and unreliable data from multiple sources.
The ATA mandates a model-based approach to data standardization which consists of:
Historically, lower-echelon information systems have been primarily messaging and display systems. As evolving systems incorporate database capabilities and require seamless interoperability with information systems at brigade-and-above, there is a pressing need for data standardization across the varied battlespace information systems and operational message sets. Efforts to standardize messages and data elements must be integrated using standard data elements defined in the C2 Core Data Model, which will be extended as needed to accommodate additional data elements and relationships. A far-term goal is to eliminate the need for message sets, such as the character-oriented Joint Interoperability Command and Control System (JINTACCS) U.S. Message Text Format (USMTF), and execute direct database-to-database transfers. Except for the sustainment of multinational gateways, elimination of character-oriented message sets is anticipated to occur around the 2005 time frame.
Technical Interface Design Plans (TIDP) provide a common standard for formatting bit-oriented messages. The TIDP for TF XXI has identified a set of VMF messages oriented on the digitization requirements outlined in the ORA for brigade-and-below. To satisfy operational requirements, IERs are being translated into VMF messages by leveraging existing/common data elements. As a result of future lessons learned during the digitization process, it may be necessary to add to or modify the current VMF message set to better support evolving operational requirements.
Other information standards included in the ATA address imagery (e.g., National Imagery Transmission Format Standard (NITFS)), graphics (e.g., Computer Graphics Metafile (CGM)), and symbology (e.g., MIL-STD 2525).
4.2.2.1.4 Human–Computer Interfaces (HCI)
Standardizing HCIs across application software to attain a user interface that presents a common appearance and behavior among Army systems within the digital battlespace requires a common set of HCI standards and a common approach to implementing them. The Army is developing guidance that will accomplish this, to be contained in documents called style guides.
Volume eight of the DoD TAFIM contains the DoD HCI Style Guide, which sets the basic graphical HCI standards for Army systems. However, the DoD Style Guide is a general document that outlines the basic display standardization needs of the larger DoD community. It does not achieve the level of detail needed for interoperable tactical support systems that exhibit a common look and feel.
User interface specifications for GCCS define the user interface for GCCS applications. This style guide is focused on the information management and X-Windows environment of the GCCS community and supplements the basic guidelines in the DoD style guide to assure that GCCS applications display a common look and feel across the GCCS platforms. The GCCS Style Guide is TAFIM-compliant and references the DoD Style Guide.
DoD HCI and GCCS user interface specifications establish the basic interface standards for Army command and control system developers. However, in both of these style guides, the primary method of user interaction is through a graphical user interface (GUI) with provisions for an alternative mode of interaction using a character user interface (CUI). Applications that present graphical displays—such as maps—are accessible only through a GUI, while applications that present non-graphical information—such as text or tables—can be accessed through either a GUI or CUI. The benefit of a CUI is that it requires far less transmission bandwidth. Since the bandwidth available to many battlespace users is very constrained, a CUI is necessary to provide them with access to their essential applications.
HCIs will be addressed as MANPRINT issues in specific BFA applications to insure that software /style guides are suitable for the echelon and application for which the software is written.
4.2.2.1.5 Information Security
Security requirements and engineering should be addressed in the initial phases of design. OA decisions regarding the security services to be used and the strength of the mechanisms providing the services are primary aspects of developing the distinct security architectures to support specific domains, using the information security standards in the ATA. They can also be used to assess the relevance of standards that can be met with government-provided components and protocols by using the ATA as a tool to judge the elements of the SA against operational security requirements, standards compliance, interoperability, and reduced costs through re–use.
Planned Enhancements to the ATA
Planned enhancements are intended to:
- Incorporate improvements based on feedback from Version 4.0 and ongoing work by the WSTA WG.
- Continue the process of replacing DoD and MIL-STDs with equivalent open commercial standards, where feasible.
- Update referenced standards and profiles to the current approved version.
- Move emerging standards to mandated standards when they have sufficiently matured.
- Reflect changes in foundation documents such as the TAFIM.
- Resolve issues arising from use of the ATA as the baseline document for a Joint TA.
4.2.2.3 ATA Migration Strategy
The Army strategy for migrating systems to compliance with the ATA is as follows:
All RFPs for new systems or significant upgrades to existing systems will be reviewed for compliance with the ATA. The ASEO serves as a member of the IPT established to review proposed RFPs or Broad Agency Announcements (BAAs) for experimental and modernization systems; reviews the RFP for compliance; and coordinates with the ADO and DISC4. The IPT and the appropriate PEO or MACOM jointly certify compliance to the MDA prior to RFP release. (See Figure 4-3).
The AAE has directed that PEOs/PMs, ATD/ACTD Managers, and MACOMs prepare and submit plans for migrating their systems to full compliance with the ATA. Each plan, consisting of a proposed implementation plan and identification of cost, performance and schedule impacts, is submitted to the ADO. The ASEO reviews these plans to determine compliance with the ATA and provides its evaluations to the ADO.
Figure 4-3 Army Digitization RFP Review Process
The first stage of the ASEO review was completed in July 1995 and addressed completeness of the initial submissions. It resulted in several requests for clarification and/or additional information. The second stage entails a technical review covering methodology, cost/schedule impacts, and acceptability.
A number of systems have already initiated ATA compliance efforts in terms of adherence to applicable guidelines, specifications, standards and documentation. For example:
It is the intent of the ADO to foster a policy of forward compatibility when technically feasible and affordable. Existing systems will migrate to ATA-compliant protocols, profiles, data elements, and message standards. However, when neither feasible nor affordable, interim measures such as translating gateways will be used to provide interoperability between legacy and ATA-compliant systems. Such interim measures must be formally approved by the ADO.
4.2.2.4 Applicability to Joint Operations
Individual digitization efforts of the four Services impact on each other due to the need for digital interoperability in a joint environment. To facilitate joint interoperability, the ATA is based on the use of existing commercial or military standards where possible. However, in those instances where new standards must be developed or existing standards must be modified, the Army’s approach is to submit applicable standards for joint approval and adoption.
Standards for data communications via CNR are specific examples of both new and modified standards which have joint applicability. Five CNR standards were submitted for DoD joint standardization review. The two most notable are:
The ATA was selected to serve as the Joint Technical Architecture baseline by ASD(C3I) on 1 December 1995.
4.2.3 System Architecture (SA)
A system architecture is a description—often graphically portrayed—of the systems solution used to satisfy the warfighter’s OA requirement. It defines the physical connection, location, and identification of nodes, radios, terminals, et al associated with information exchange. It also specifies the system performance parameters. The system architecture is constructed to satisfy operational architecture requirements according to the standards in the technical architecture.
Current plans are to develop the SA for Force XXI in conjunction with a planned series of AWEs. The first increment is the SA for the TF XXI AWE. Following this AWE, system architectures for Division XXI and Corps XXI will be developed.
The SA provides structure for the design and a methodology for implementing Force XXI’s system-of-systems environment. It will support assessments of tasks, responsibilities, and risks. Evaluations of the SA will support estimates on the adequacy and feasibility of the technical and management approach, and a crosswalk against requirements. The SA conveys to both combat and materiel developers the operational considerations and systems solutions that are proposed to meet the stated requirements. The SA can also be the baseline for evaluations of system designs, such as the Applique. Before design is completed, the SA will be assessed to determine if:
After design efforts are completed and implementation has begun, the SA serves as a basis for measuring progress; developing checklists of actions to be accomplished; and developing test and evaluation plans. It should also be possible to use the SA as a configuration management tool to ensure overall system operational integrity is attained within and between each weapon system platform and node.
Due to the complexity of a system architecture and in order to support ongoing systems engineering efforts, a number of perspectives have been made available or are in the process of being developed to portray the TF XXI System Architecture. These include:
4.2.3.1 System Architecture Development Process
The Force XXI SA is being developed by PEO C3S as the ADO’s executive agent and system integrator for the overall Force XXI development process. PEO C3S established the Force XXI Integration Office (FIO) and assigned it responsibility for developing the Force XXI SA, with initial priority on the architecture supporting the TF XXI AWE.
The FIO is following a three-axis approach:
The IPT axis consists of the effort to capture the information necessary to construct the SA and disseminate its products for feedback and use. Focus of the 16 teams established by the FIO (listed below) is on the Horseblanket and related equipment configurations.
The systems engineering axis consists of the efforts to engineer the architecture and validate that it satisfies the OA within the constraints of the TA.
The third axis entails the effort to develop the infrastructure (hardware, software, and database) required to design the SA; support the system engineering efforts; and generate the representations. These representations, beginning with the Horseblanket, are developed incrementally and widely distributed for review, comment, and information. More detailed representations, such as the data view, are primarily directed to engineers and computer scientists who are responsible for developing the interfaces between the component systems.
|
NEWSLETTER
|
| Join the GlobalSecurity.org mailing list |
|
|
|
