Army Digitization Master Plan (ADMP)

CHAPTER 4 - DIGITIZATION EXECUTION

Major Initiatives

In developing the Army Digitization Campaign Plan, four major thrusts were identified. These are: (1) acquiring key hardware and software components using acquisition streamlining; (2) integrating the existing battlefield communication systems into a seamless "Tactical Internet"; (3) employing common data, message formats and, where feasible, common software to assure integration and interoperability across all embedded and Command and Control (C2) systems; and (4) conducting experiments to define near-term augmentations to the "Tactical Internet" and the next generation Battlefield Information Transmission System (BITS). These thrusts, shown in figure 4-1, conducted in accordance with the Technical, Operational, and System Architectures as recommended by the Army Science Board (ASB), and in full compliance with DoD architectural guidance will be executed in a three phase process. The intent is to quickly digitize the battlefield by employing current technologies to acquire, exchange, and process critical information throughout the battlespace and to evolve this capability to reflect both insights gained from Advanced Warfighting Experiments (AWE) and opportunities for technology enhancements.

Figure 4-1 ADO Campaign Plan

The following paragraphs provide detailed explanations about the phased approach, each of the four major Army Digitization Office (ADO) thrusts, the role of the three architectures, and the experimentation and evaluation plan.

4.1 Phased Approach

Program Structure

The Army's digitization effort will be executed in three phases as depicted in figure 4-2 below.

Figure 4-2 Program Structure

Phases 1 and 2 support the Army's efforts to infuse information technologies, refine tactics, techniques, and procedures and to assist in the design of the 21st century Army. Phase 3 will produce hardware and software to equip additional Force XXI units.

4.1.1 Phase 1. Brigade Task Force XXI -- Concept Exploration

This phase began with Army approval of the Horizontal Integration of Battle Command Mission Need Statement (HIBC MNS) in October 1994 and continues through the conclusion of Brigade Task Force XXI, the Army's first major AWE employing a wide range of information technologies. The FY 95 AWEs together with the Brigade Task Force XXI experiment, consisting of nine months of intensive training on the use and employment of information technologies and culminating in a force-on-force exercise at the National Training Center (NTC), will evolve Doctrine, Training, Leader Development, Organization, Materiel, and Soldiers (DTLOMS) for a brigade size task force.

The Force XXI Battle Command Brigade and Below (FBCB2) contract, competitively awarded in January 1995, will provide hardware -- termed the applique -- software, platform integration as well as logistics support and training support. Ongoing contractual vehicles will be used to product improve the communications systems and acquire the routers that will provide seamless interoperability.

4.1.2 Phase 2. Division and Corps XXI -- Demonstration/Validation, Engineering and Manufacturing Development

This phase begins with a milestone I/II review conducted at the conclusion of the Brigade Task Force XXI AWE and continues through the conduct of the corps level AWE called Corps Task Force XXI. During this phase the focus will change from brigade and below to division and corps level. Software and hardware products will be sufficiently mature to provide the exercise unit with a contractor supported go-to-war capability. Training and support products will be developed in preparation for a Deployment decision in FY 99.

The basic Corps Task Force XXI contract will be competitively awarded in FY98. The scope of the Corps Task Force XXI contract will be similar to the previous FBCB2 contract. The winning contractor will have overall system responsibility, make software updates, and provide logistics support. The contractor will also provide hardware to equip two division headquarters and a corps headquarters, needed to support the Corps Task Force XXI experiment.

The Corps Task Force XXI contract will contain an option to procure two additional sets of brigade hardware. At the conclusion of Corps Task Force XXI, one division; two additional division headquarters; and one corps headquarters will be equipped with modern information technologies, assuming that ADO Program Objective Memorandum (POM) 97 funding requirements are supported.

Also during this phase, the Army will augment the "Tactical Internet" by incorporating the Near Term Data Radio. This radio will provide improved capacity and will serve as the data transmission backbone for brigade and below.

4.1.3 Phase 3. Force XXI --Deployment

A Milestone IIIA review will be conducted following the Corps Task Force XXI AWE. This milestone will trigger the Deployment phase award for a full corps set of equipment. The Deployment phase contract will be competitively awarded and will contain several options, structured to meet the normal 12 month funded delivery periods.

During this phase, the Army will transition to the next generation "Tactical Internet", termed the BITS.

4.1.4 Resources

The current funding profile, shown in figure 4-2, is expected to provide fiscal resources to support the initial phases of the digitization effort. Additional hardware and software requirements are expected to emerge during the experimentation process. As these additional needs are validated, the funding profile will be adjusted accordingly. Digitization resources which exist in other programs are not included in this funding profile.

4.1.5 Execution Strategy

4.1.5.1 Evolutionary Acquisition

An evolutionary strategy will be used to develop FBCB2 software. Users will be involved with the software development from the beginning of the program. Each US Army Training and Doctrine Command (TRADOC) Battle Lab, various TRADOC Directorates of Combat Developments, Program Executive Offices, and Army Materiel Command (AMC) Research, Development, and Engineering Centers (Reds) will be connected through the Army Interoperability Network (AIN) to the FBCB2 contractor's development facility. User "juries" will help the developers to design the most effective interface designs. As the FBCB2 software functions mature, the AIN will also permit users to remotely operate with other battlefield operating systems (BOS) using the Digital Integrated Laboratory (DIL) of the AMC Communications and Electronics Command (CECOM). The DIL is a collection of real and simulated command, control, and communications (C3) facilities that, when connected to the FBCB2 system, will assist TRADOC in the development of tactics, training, and procedures. Frequent software releases will also aid in keeping user interest and evolving them in the requirements process.

4.1.5.2 Standards Based Implementation

Both the information processing and information transport components will utilize widely-used open system standards and layered architectures as prescribed in the Command, Control, Communications, Computers and Intelligence (C4I) Technical Information Architecture. Open systems are characterized by their use of standards to define services, interfaces, and formats. Implementing well defined, widely known, and consensus based standards allows the Army to leverage the commercial marketplace's investments and to promote the development of both interoperable and integrated systems.

All Army systems will be required to comply with the standards-based architecture. The Army Acquisition Executive (AAE) is the Army's Technical Architect responsible for codifying and maintaining the Army Technical Architecture, ensuring that all Army information systems are developed in compliance with the Technical Architecture, interfacing with DOD and other Service C4I architecture/interoperability offices, and ensuring that the mandated Technical Architecture is included in procurements. The DIL will validate system compliance with prescribed standards and protocols. It will also certify interoperability between systems as a prerequisite to participation in AWEs and fielding to a tactical unit.

4.1.5.3 Embedded Platforms

The use of appliques is intended to provide C2 capabilities to platforms that either have no embedded C2 capability or whose existing capability, in terms of computer processing power, displays, etc., is inadequate to meet emerging user requirements. The applique will continue to be the materiel solution for those platforms, such as the High Mobility Multipurpose Wheeled Vehicle (HMMWV), which are not planned to be upgraded with an embedded capability. For other platforms, such as the Abrams tank and the Bradley Fighting Vehicle, digitization related modifications will be included in the larger product improvement programs. These product improvement programs will encompass necessary software modifications to comply with the Technical Architecture and use common software modules. This may also require hardware modifications including processor, memory, storage and displays. While these programs will continue to be managed by the affected program manager, the ADO will insure that product improvement programs incorporate the Army's Technical Information Architecture and are designed to achieve the required degree of interoperability.

4.1.5.4 Other Interfacing Systems

Systems running the FBCB2 software will have to interoperate with other information systems on the battlefield and potentially in garrison. Common data elements and message structures and, where appropriate, common software modules, consistent with the Technical Architecture, will be mandated to ensure seamless interoperability. Common data elements will be defined consistent with the DOD C2 Core Data Model process. A preliminary set of message structures has been developed and submitted for Joint accreditation and use.

4.1.5.5 Communications Systems

The initial digitization effort relies on communication systems that are currently being fielded. Existing contracts to improve the SINCGARS, EPLRS, and the Mobile Subscriber Equipment (MSE) system must continue as planned to enhance the capabilities of the individual communication systems and acquire the routers to interconnect these systems into the "Tactical Internet". These systems will remain under the management control of the PEO for Communications (COMM) and the individual program managers (PMs).

Future communication systems may augment and eventually replace components of the "Tactical Internet"; however, they will be required to internetwork with the communication systems defined as part of the Army's architecture. Satellite communications (SATCOM), both military and commercial, are providing higher bandwidth beyond line-of-sight capabilities to link diverse units across the digital battlefield and from Continental United States (CONUS) to force projection battlefield locations. Commercial systems offer significant capacity at lower cost while military SATCOMs provide secure capability which can operate under battlefield conditions. Emerging direct broadcast satellite capabilities will make tailored, relevant, and timely data available to warfighters at all echelons.

4.1.5.6. System Integration

During each phase of the digitization program, a prime contractor will have overall system responsibility, but will not have total execution responsibility. In order to horizontally and vertically link weapons, sensors, and C2 systems, many existing and future contracts must be modified. The prime contractor will be responsible for coordinating interfaces with other primes and assisting the system engineer for Technical Architecture in configuration control and maintenance of Technical and System Architectures.

4.1.5.7 Non-Developmental Items

The use of non-developmental hardware and software is a major component of the initial digitization acquisition strategy. Emphasis is placed on maximizing the use of COTS hardware and determining the degree of required ruggedization. There are substantial cost differences between commercial and ruggedized computers. Even greater differences exist between commercial and nearly militarized computers. The intent of the experiments is to determine whether commercial computers can be adapted to operate in tactical environments.

Non-Developmental Item (NDI) software, whether COTS or government furnished, will be used extensively. The FBCB2 contractor has been given two existing, government owned software application programs (IVIS and B2C2) which collectively provide most of the initial functions needed to support the Brigade Task Force XXI experiment. It is intended that the software modules developed by the FBCB2 contractor will be provided for use by other Army information system program efforts.

4.1.5.8 Acquisition Streamlining

The ADO has been charged by the Army Acquisition Executive (AAE) with developing and implementing acquisition streamlining concepts to support the Force XXI objectives. One of the primary goals of Force XXI is to redesign the operational Army based on the widespread use of information technologies. The Army is establishing a standards based Technical Information Architecture. The Technical Architecture will adhere to many commercial standards and protocols. However, contractors will be required to use specific standards adopted by the Army to insure interoperability between systems.

4.2 Major Thrusts

4.2.1 Thrust 1 - Acquisition

The ADO's acquisition plan for providing digital capability to Force XXI units is called the Force XXI Battle Command, Brigade and Below (FBCB2) effort. The ADO will coordinate and integrate the FBCB2 effort with the PEO for C2 Systems. The FBCB2 contractor will develop the platform integration package, with training and logistics functions. In the future, these functions will become part of the normal training and logistics processes used for all systems.

To maximize the advantages of information technology across the force, participants must be equipped with digital systems. Since very few systems at brigade and below possess a digital capability now, the capability must be added as an "applique".

Applique Systems

For a platform that has no capability now, the applique will consist of a Global Positioning System (GPS) receiver, a computer unit (commercial, ruggedized or militarized), and an interface to the Single Channel Ground and Airborne Radio System (SINCGARS), and/or Enhanced Position Location Reporting System (EPLRS) radio. A common "core" application software capability will reside in all appliques, regardless of platform. Additional software modules will provide the interface with embedded systems on the M1A2 tank, AH-64, and OH-58D aircraft. Selected platforms from the Marine Corps and the Air Force will also require appliques to participate in the experiments.

The initial set of appliques will be used primarily for situational awareness and operational control. The exact applique is system dependent, based on the user's need, and varies in ruggedness from commercial through militarized items. Applique solutions are not practical on all platforms. On those where space, weight, power, electrical interference, or human interface restrictions are encountered, or where the applique may restrict mission capability, other solutions must be identified. Three options exist for appliques:

Commercial Off The Shelf (COTS): The installation kit provides shock and some environmental protection. The COTS approach permits replacement of processing and display capability relatively inexpensively.
Ruggedized: Shock and environmental protection, equivalent to that used for industrial applications, is external to the COTS equipment. Future upgrades may be accomplished on selected components.
Militarized Items: Shock and environmental protection is integrated into the computer. The installation kit provides mount and platform integration.

In addition to the applique hardware, common application and support software will be provided. The software will contain, as a minimum, the functionality provided by the C2 portion of the InterVehicular Information System (IVIS) found in the M1A2 tank and the Brigade and Below Command and Control (B2C2) prototype software. The software developed will meet open system standards and be non-proprietary except under the most compelling circumstances. The software will be forward compatible with the main stream of commercial hardware and software developments to allow ease of new technology insertion. The applique contractor will be encouraged to reuse and incorporate existing government and commercial software.

The contractor will have overall system responsibility. Contract tasks include:

Developing FBCB2 software.
Acquisition of four types of computer processors (appliques) that include commercial, ruggedized, and nearly militarized platform-mounted configurations as well as a hand-held configuration for use by dismounted forces.
Designing and producing installation kits needed to mount the computers on representative samples of Army, Marine Corps, and Air Force major weapon systems and C2 platforms.
Providing contract logistics support for FBCB2 hardware and software.
Creating interface documents along with recommended engineering changes needed to install either an applique or the FBCB2 software in embedded weapon systems.
Providing the means to technically manage the "Tactical Internet" communication infrastructure.

The basic contract provides software, hardware, and systems support to equip most of a modernized brigade organization along with its associated divisional support elements, such as artillery and engineer support, as well as accommodate data inputs from the corps level.

The FBCB2 contract will contain one option to procure additional hardware, make software changes, and provide systems support needed to conduct the Division Task Force XXI AWE. The precise scope of the option award will be based primarily on feedback obtained from data taken during the Brigade Task Force XXI training period. The hardware will be sufficient to complete the fielding of the modernized brigade, to fully equip the division headquarters, and to equip only those corps level units needed to fully exercise command, control, and intelligence inputs to the division headquarters.

4.2.2 Thrust 2 - "Tactical Internet"

Figure 4-3 Tactical Internet

Seamless Connectivity

Reliable, seamless communications connectivity is required to support the applique, other C2 systems and embedded systems. The initial digital system consists of space based assets, the EPLRS, the SINCGARS, and the Mobile Subscriber Equipment/Tactical Packet Network (MSE/TPN). These digital transport capabilities are key to moving information among the platforms and C2 nodes. The goal is to achieve seamless information transfer horizontally and vertically on the battlefield.

Gateways Provide Seamless Connectivity

The term "Internet" is appropriate because of the functional similarities to the commercial Internet and because actual Internet technology is being used. When sending messages, "Tactical Internet" users will only have to concern themselves with message addresses just as commercial Internet users have to address electronic mail. Commercial Internet technology such as routers and gateways, and protocols such as Transport Control Protocol (TCP) and the Internet Protocol (IP) are the key to providing seamless connectivity between the existing tactical communications systems. Unlike the commercial Internet, the "Tactical Internet" will be operated as a SECRET high system. All directly connected host computers will be capable of operating up to the SECRET level and therefore direct connections to the UNCLASSIFIED commercial Internet cannot be permitted. There is, however, great interest in the new end-to-end encryption devices that will permit UNCLASSIFIED users to use the SECRET high "Tactical Internet" to access UNCLASSIFIED computers connected to the commercial Internet. This capability is being pursued particularly for the Combat Service Support users who typically operate UNCLASSIFIED applications, and need to communicate in a split based mode with large computers in the CONUS.

Improved versions of the three primary Army tactical communications systems—EPLRS, SINCGARS, and MSE/TPN—will all be needed to move the ever increasing amount of digital data required on the modern battlefield. Capabilities will also exist to interface commercial and military SATCOM to the "Tactical Internet" which will provide unprecedented capacity and access to very low echelon units. In the near-term, the three terrestrial communication systems will be combined through commercial Internet routers to form a complete, seamless system that will provide the tactical equivalent of the Internet architecture for the initial brigade-sized task force and division digitization experiments. Tactical Multinet Gateways (TMGs), which are off-the-shelf commercial routers, and Internet Controllers (INCs), which are single circuit card, militarized Internet routers incorporated in the SINCGARS mount, provide the ability to send messages automatically between the tactical networks.

SINCGARS improvements include reduced co-site interference, improved error correction and net access delay, and an interface to Global Positioning System devices to obtain accurate time of day and position location. Collectively, these improvements will greatly increase data communication ranges and increase the throughput from 1.2kbs to 4.8kbs. Initial Electronic Proving Ground test results indicate that SINCGARS will be able to reliability pass data at 4.8kbs at ranges up to 35 kilometers in a benign environment.

The EPLRS system is incorporating Very High Speed Integrated Circuit technology which will increase the throughput of individual radios from 4kbs to 12kbs. Produceability improvements are also being made which will reduce unit production cost and ensure the continued availability of repair parts for the existing systems. Finally, the Network Control Station functions, which are currently performed by a dedicated set of HMMWV mounted equipment, are being redesigned to operate on a single computer that will be collocated with the Integrated System Controller (ISYSCON) facility. The NCS downsizing program is a Joint USA EPLRS-USMC Position Location Reporting System (PLRS) initiative.

The MSE/TPN program is upgrading routing protocols from Exterior Gateway Protocol (EGP) to Border Gateway Protocol (BGP). This change will substantially reduce the bandwidth required to exchange routing information between routing devices in different networks.

Improvements to each of these systems are needed to make the "Tactical Internet" viable. While the use of commercial Internet protocols provide the much sought after seamless connectivity between the different networks, seamlessness does not come for free. Internet protocols increase data capacity requirements since additional header information is added to each message. The Internet routers exchange routing and status information which also increase data capacity requirements. Even with the improved data capacity of SINCGARS, EPLRS, and MSE, these systems provide relatively small communications trunks compared to commercial, fixed locations. As a result, a comprehensive modeling and simulation effort is also required to determine the optimum parameters for the use of Internet protocols in a dynamic military environment which has relatively limited communication links.

Another key component of the "Tactical Internet" is the ISYSCON program. Currently the ISYSCON program is developing the capability to technically control networks at brigade and above. Since Tactical Multinet Gateways and Internet Controllers must also be technically controlled, additional ISYSCON capabilities are being added to control the "Tactical Internet" at brigade and below.

The Signal Center, in conjunction with AMC (CECOM), is investigating the operational and training impact of the "Tactical Internet". A series of battle lab experiments, Joint Chiefs of Staff sponsored Joint Warfighting Interoperability Demonstrations (JWIDs), and AWEs will provide the experimental basis to determine if additional personnel are needed, to determine training and skill levels, and to recommend changes to communications tactics and procedures.

PEO COMM, with the support of AMC (CECOM) and the Signal Center, is responsible for developing the "Tactical Internet" in accordance with the Army's Technical Architecture. The improvements to the radios, ISYSCON, and the modeling and simulation will all be completed by May 1996.

4.2.3 Thrust 3 - Integration of Battlefield Operating Systems

Integration of new or evolving digitization technology presents many challenges in synchronization of diverse acquisition and development program products as well as achieving the technical integration of these products into the overall system of systems supporting the digitized force. The integration effort will successfully tie all of the components of the ABCS into a seamless network from the soldier through the tactical and operational levels to the sustaining and strategic level.

The ADO, in conjunction with representatives from the PEOs, Department of the Army, Deputy Chief of Staff for Operations and Plans (DA DCSOPS), AMC, and Secretary of the Army Research, Development, and Acquisition (SARDA), will integrate the acquisition and technology development programs. PEO CCS has been designated by the ADO as the responsible agent to ensure technical integration of all the systems within the digitized force. PEO CCS' contractor will be responsible for the technical systems integration of FBCB2 hardware and software across the entire combined arms team. In support of this requirement the FBCB2 contractor has a task to perform systems engineering, integration, and qualification to support implementation of the FBCB2 software into platforms with existing embedded systems (e.g., M1A2 systems enhancement program). Under the guidance of PEO CCS, he will work closely with PMs whose weapons platforms will be fitted with appliques and/or FBCB2 software. He will identify necessary upgrades in weapons system computing platforms and provide system engineering services to PMs as necessary. The ADO will coordinate the efforts between the software developers and the platform developers, and will assist platform developers in demonstrating system interoperability prior to fielding.

4.2.3.1 Embedded Systems

Embedded systems are platforms with digital system components providing functions and processes which are integrated to such an extent that they can not be considered as discrete entities during development, testing, or production of a system. Such systems can include fire control, position/navigation, diagnostics and communications equipment found on the M1A2 Abrams, Apache Longbow, and OH-58D Kiowa Warrior weapon systems. The software and hardware of these platforms may also perform common battle command functions such as situation awareness, use common digital terrain data and receive/transmit digital messages.

Some embedded digital systems are wholly contained within a platform type and their standards and protocols for internal connectivity are defined within the purview of the PEO. The PEO must consider cost while effectively applying standard development concepts such as growth, open system architectures, flexibility, and interoperability with other platforms.

Modular, multi-function hardware designs will be adopted. Emerging technology affords the opportunity for a significant shift away from single-purpose designs to multi-purpose implementations where functions are implemented on removable, upgradable circuit cards, microchips, or in the software.

Embedded digital systems that interact with other dissimilar weapon systems or C2 nodes must, as a minimum, use common message sets. Digital communications, standard data protocols, icons, and applications are required to pass the "same information" for applications such as overlays, calls for fire, and spot reports. These requirements will be documented in Interface Control Documents (ICD).

The embedded digital systems already in use or planned to be fielded in the battlefield functional areas are part of the digital System Architecture. This System Architecture will include interoperability with the embedded command and control systems. The challenge of integration remains at the lower levels, where existing legacy systems have been developed to provide vertical "stovepipe" information flows for specific battlefield functional areas. As such, the FBCB2 contractor has a task to develop System/Subsystem Segment Interface Control Documents (ICDs) for the approximately 28 platforms (e.g., M1A1, M2A2, M113, HMMWV) to be digitized. The ICDs will document interfaces to existing platform power, MIL-STD 1553 data bus, communications, navigation, and sensor sub-systems as appropriate. The ADO is developing a series of MOAs with all the PEOs which develop platforms with embedded systems. The MOAs require the PEOs and PMs to ensure their systems are compliant and interoperable with the Army's Technical Architecture and common operating environment (COE). They will continue to be responsible for automated platform management functions. Platform PMs will be required to:

Provide support to the FBCB2 Program Manager which will include providing technical data packages to the applique prime contractor for development of installation kits and interfaces; providing technical assistance in evolving/defining system integration requirements; and making platforms available for technical integration testing.
Develop migration plans that lay out a strategy for migrating their systems to the evolving Technical Architecture to include MIL-STD-188/220(), Variable Message Format (VMF), the Command and Control Core Data Model and the COE.
Integrate the FBCB2 software supplied by the PEO CCS as an additional application or task to share the host processor with existing weapon system specific applications.
Develop and document in the program acquisition strategy the program funding and schedule changes to support migration to the digitized force. Incorporate digitization test criteria in the system Test and Evaluation Master Plan.
Address the critical elements of the digitization initiative in all program reviews.

4.2.3.2 Non-Embedded Legacy Systems

There are numerous non-embedded legacy systems currently fielded that will be a part of the digital battlefield. These systems present a wide range of integration issues associated with protocols, data standards and message exchange. For example:

ATCCS currently utilizes the United States Message Text Format (USMTF) as its primary message exchange system.
The Interim Fire Support Automated System (IFSAS) and TACFIRE use the TACFIRE protocol and message set.
The Marine Corps Tactical Command and Operations (TCO) System employs the Marine Tactical System protocol and message set.

To reduce the risk associated with the development of FBCB2 software and the "Tactical Internet", backward compatibility will be selectively implemented. The FBCB2 software and "Tactical Internet" will be baselined on the MIL-STD 188-220 () and the Task Force XXI VMF Technical Interface Design Plan (TIDP) which have been submitted for Joint approval, as well as, the DOD adopted TCP/IP and Internet Protocols.

The ADO will work with various legacy PEOs and PMs to obtain forward compatibility with FBCB2 software and the "Tactical Internet". For example:

PEO CCS will develop a USMTF to VMF translator to achieve interoperability as ATCCS migrates to the Joint VMF.
PM AFATDS will implement the Task Force XXI VMF fire support messages on a timeline consistent with the FBCB2 software effort.
PEO COMM will implement MIL-STD 188-220 () and DOD adopted TCP/IP and Internet Protocols in the SINCGARS SIP program.

In those cases where schedule, funding or technical considerations do not allow integration and interoperability in the near-term; SINCGARS SIP, applique hardware, and FBCB2 software maybe provided as an interim capability.

4.2.3.3 System Engineering Process

The digitization effort requires change to almost every platform or automated system in the Army. The Army Acquisition Executive has directed that a Systems Engineering Office be established to ensure that all systems which will be part of the digitized force conform to the standards established in the Technical Architecture and are interoperable with the other elements of the System Architecture. The System Integrator will implement the System Architecture.

4.2.3.3.1 Certification of Compliance with the Technical Architecture

One of the responsibilities of the System Engineer is to ensure that all systems and system elements which are part of the digitized system comply with the Technical Architecture and other standards as directed. The System Engineer and his staff will review all developmental and fielded systems for compliance with implementation of the COE, the C2 Core Data Model, use of Ada, Human Computer Interface standards, MIL STD 188/220 (), and VMFs. The Systems Engineer will also ensure that any prototype, developmental, and fielded system which will be connected to the digital force is interoperable and has adequately considered the C2 Protect/Vulnerability issues for that system.

4.2.3.3.2 Digital Integration Laboratory (DIL)

To the maximum extent possible, new hardware and software will be developed centrally and provided to PMs or ATD/ACTD managers for incorporation into their products. In other instances, programs and products may develop hardware and software with equivalent functionality. In all cases, these systems must be interoperable.

Recognizing the need to certify system and system element interoperability, the Force XXI Board of Directors directed establishment of a DIL. The DIL, located at and operated by CECOM, is the focal point for many other Army agencies which have a role in interoperability testing and certification.

The DIL is one of the primary tools supporting the System Engineer, System Integrator, and system integration contractor in the development of FBCB2 battle command software. The PEOs uses the DIL to connect to the TRADOC Battle Labs for early software prototyping and experimentation. This networked prototyping environment will facilitate getting quick turn around evaluation of software functionality and soldier-machine interfaces by software user juries.

The DIL will also coordinate efforts to integrate other AMC interoperability labs and Battle Labs to provide a virtual brigade capability. The operational test community requires this capability to support the "rolling baseline" evaluation of FBCB2.

4.2.4 Thrust 4 - Battlefield Information Transmission System

Push to Accelerate Improved Digital Capabilities

While the "Tactical Internet" described in Thrust 2 will substantially improve communications connectivity, the digital data load of the future is expected to exceed the capacity of the "Tactical Internet". BITS, as illustrated, is an umbrella concept that is intended to capitalize on the use of emerging commercial systems, such as direct broadcast satellites and digital cellular telephones, and commercial component technologies such as Digital Signal Processing (DSP) chips and Monolithic Microwave Integrated Circuits (MMIC) in military unique systems. DSP and MMIC components are particularly attractive because of their ability to substantially improve performance and to reduce size, weight, power, and unit cost.

Figure 4-4 BITS Umbrella Concept

The BITS acquisition strategy has near and far term paths. The Army has an immediate need to acquire more data radios to support Brigade and Below communications. The EPLRS will be used during the brigade level Task Force XXI Army Warfighting Exercise.

Figure 4-5 BITS Acquisition Strategy

However, there are insufficient EPLRS radios to support the Division and Corps level exercises. Since EPLRS technology was developed in the mid-80s and has a relatively high unit cost, the Army will solicit industry for a Near Term Digital Radio (NTDR) that offers the potential for increased performance significantly below the cost of EPLRS. PEO Communications is preparing a performance based specification which maximizes the use of commercial parts, specifications, software, and standards that will be released to industry 3rd Quarter FY 95. A contract for 400 NTDR radios with an option for up to 700 more will be competitively awarded 1st Quarter FY 96 assuming that industry can respond to the Army's performance and schedule requirements. If the NTDR program cannot meet the Division XXI AWE schedule and quantity requirements, the Army will be prepared to award a contract for up to 400 additional EPLRS. At the conclusion of the Division and Corps Task Force XXI AWEs, the Army plans to procure up to 5,000 NTDRs to equip the highest priority (Force Package I) Army units.

The far term BITS strategy is currently being developed by the Directorate of Information Systems for Command, Control, Communications and Computers (DISC4 ) and will be completed in March 95. The far term strategy will provide a management framework and long term focus for the large number of ARPA projects, Army Advanced Technology Demonstration (ATDs) projects, and Battle Lab Warfighting Experiments (BLWEs) that are addressing future communications needs. The far term strategy will use an experimental process to assess military utility, cost effectiveness, and requirements documents based on the needs to participate in Major Regional Conflicts and Operations Other Than War (OOTW)

4.3 Architectures

Architectures Support Interoperability

To achieve the vision and goals of Force XXI, all battle command systems must be flexible and interoperable. The supporting battle command information infrastructure must support the ability to structure a force rapidly and efficiently to meet any future contingency. Furthermore, given the requirement for a force projection Army, and the requirement for split-based operations, interoperability and flexibility are necessary among tactical systems; post, camp, and station information systems; and Standard Army Management Information Systems (STAMIS). Moreover, the need for interoperability and interconnectivity of battle-command systems is not just an intra-Army issue. The need to conduct Joint and Coalition operations requires open, flexible, and interoperable information infrastructures and the ability to facilitate training in a synthetic theater of war (STOW).

In 1994, the ASB presented the results of its Summer Study on a Technical (Information) Architecture for command, control, communications, computers, and intelligence (C4I). In their final briefing, the ASB defined Technical Architecture, differentiated it from Operational and System Architectures and recommended a process and an organizational structure for developing and enforcing an Army-wide Technical Architecture. The Army has implemented the ASB's recommendations and has put in place a mechanism for developing all three architectures.

4.3.1 Operational Architecture

As defined by the ASB and accepted by the Army, an Operational Architecture defines what is to be built. It describes who needs to exchange information, what information needs to be exchanged, and how that information will be used. The Operational Architecture is being developed by TRADOC with technical support from PEO CCS.

The architecture will describe the functions, processes and data required to digitize the battlefield, using the Integrated Computer Aided Manufacturing (ICAM) Definition (IDEF) method IDEF0 process model and IDEF1X data model. Since the "Tactical Internet" allows communications to be dynamically routed, a logical connective diagram will also be developed to graphically portray required connectivity between force elements: operations facility to operations facility, operations facility to weapon systems, sensors to operations facility/shooters, and the like. The description also includes the types and frequency of the information sent between those elements as well as performance bounds (e.g. speed of service required). The architecture will require a detailed breakout of functions, processes and information flow and will be developed over an extended period of time as an evolutionary process. The initial focus will be on developing the Brigade and Below portion of the battlefield to include Joint information exchange requirements. Identification of the force elements to be a part of the digital battlefield completes the Operational Architecture.

4.3.2 System Architecture

The System Architecture shows the specific hardware needed to provide the connectivity required in the Operational Architecture. Both architectures are very closely linked. The System Architecture is a description of the physical connectivity of an information system, which includes: identification of all equipment (radios, switches, terminals, computers, inter-networking devices, and local area nets (LANs) and their physical deployment; the specification of such parameters as the bandwidth required on each circuit; and the description, including graphics, of technical characteristics and interconnection of all parts of an information system. The System Architecture process entails trade-off analyses to optimize overall network and system performance within the performance bounds defined in the Operational Architecture.

4.3.3 Technical Architecture

The Technical Architecture is defined as a minimal set of rules governing the arrangement, interaction, and interdependence of the parts of an information system. The purpose of the Technical Architecture is to ensure that a conformant system satisfies a specified set of requirements. The Technical Architecture is analogous to the building code for homes. It does not say what to build (that is defined by the user in the Operational Architecture), nor does it say how to build (that is defined by the developer/integrator in the System Architecture); but it does say that when you build you must adhere to the set of rules/standards that it specifies-the standards the "building inspector" enforces.

The standards laid out in the Technical Architecture establish the framework for achieving interoperability and commonality among component hardware/software and seamless connectivity between communications on the digital battlefield. Standards facilitate less costly component upgrades through technology insertion. An open systems architecture is being adopted that is compliant with DOD standards and which makes maximum practical use of commercial standards, consistent with mission requirements. Where commercial standards prove inadequate, efforts will be initiated to incorporate required military features into the system and if possible into the commercial standards. While all Army information systems will be required to comply with the Technical Architecture, specific migration schedules will have to take into account planned system upgrade windows.

The Army Technical Architecture consists of four elements: (1) the information processing profile; (2) the information transport profile; (3) information standards; and (4) human-computer interface.

Figure 4-6 Technical Architecture

4.3.3.1 Information Processing Profile

The Information Processing Profile defines a detailed suite of commercial and government standards and associated implementation profiles consistent with the TAFIM Technical Reference Model and standards profile. Compliance with a standard information-processing profile promotes the development of integrated applications, that is, applications that share functions and data.

Common Operating Environment

The COE is the set of integrated support services that support the mission application software requirements. In addition, it provides a corresponding software development environment, architecture principles, and methodology, which assists in the development of mission application software by capitalizing on the infrastructure support services.

Efforts are underway to define and evolve a COE, both within the Army and in the Joint GCCS. The Army is committed to using the COE not only for echelons above corps (EAC) C2 systems but also for tactical C2 systems. Where necessary, the Army will extend the JCOE to fulfill support requirements for battlefield C2 systems. The Army will provide those COE extensions to other Services and GCCS, as requested.

The requirement for a COE is documented in the draft ABCS Common Operating Environment/Common Applications (COE/CA) ORD. This ORD requires the migration of the separate Army C2 Systems into one integrated system. Functional area applications will be ported to a COE with common data elements and structure to provide assured horizontal and vertical interoperability and decreased design and training costs.

Figure 4-7 Mid Term (FY96) Common Operating Environment

One of the fundamental concepts of the COE is that shared services will be available to other applications through program level interfaces. These shared services comprise the COE. These interfaces will be designed and documented so they are easy for other developers to understand and use. The agreement is that these APIs will be baselined and not subject to change unless agreed t o by the affected parties through a formal configuration management procedure.

4.3.3.2 Information Transport Profile

Information Transport Profile

The information transport profile defines the communications support required to provide seamless, reliable, and timely data exchange between users, regardless of the specific communication system(s) that they access. Communications systems and related network interfaces define the topology of the system; common protocols provide the "glue" necessary for seamless data exchange between users. A communications system conformant to the Open System Interconnection (OSI) Reference Model includes services of all appropriate layers plus the physical transmission media and the support and mission-area applications. These services may be grouped into functional levels that represent major capabilities, such as switching and routing, data transfer, and applications support.

Figure 4-8 OSI Reference Model

The Model for Open System Interconnection is explained below. It groups the functions and protocols necessary to establish and conduct communications between two or more computer systems into seven layers.

The Transmission Level (below the OSI layer 1) provides all of the physical and electronic capabilities that establish a transmission path between functional system elements (wires, leased circuits, and interconnects).
The Network Switching Level (OSI layers 1 through 3) establishes connectivity through the network elements to support the routing and control of traffic (switches, controllers, network software, etc).
The Data Exchange Level (OSI layers 4 through 7) accomplishes the transfer of information after the network has been established (end-to-end, user-to-user transfer) involving more-capable processing elements (hosts, workstations, servers, etc).
The Applications Program Level (above the OSI) includes the support and mission area "non-management" application programs.

The common thread in moving to a single network will be the use of DOD and de facto Internet protocols, specifically TCP/UDP and IP at layers 4 and 3b, respectively. At the lower layers (1-3a), unique protocols will continue to exist to accommodate each of the several communication systems. Most notable is MIL-STD 188-220 (), which is used with Combat Net Radio and is currently under revision.

4.3.3.3 Information Standards

Information standards, encompassing standard data elements and message standards, provide the basis for information sharing across boundaries. Without such standards, it is necessary to build and maintain individual interfaces, not only a costly proposition but one which often results in inconsistent and unreliable data received from multiple sources.

The ASB has recommended a model-based approach to data standardization which consists of:

An activity model that shows the relationship between an activity and the information that it uses or produces. The Integrated Computer Aided Manufacturing (ICAM) and the Integrated Definition Model (IDEF0), provide standardized procedures and diagramming conventions consisting of: (1) node trees which graphically portray activities hierarchically; (2) context diagrams which show the highest level activity and its inputs, controls, outputs, and mechanisms; and (3) decomposition diagrams, which show lower-level activities and their information relationships. Documenting requirements such as operational requirements analyses and associated user functional descriptions in the IDEF0 conventions will provide a common way to depict the processes and information requirements within and between functional areas. Efforts have been initiated to depict the information flows identified in the brigade and below Operational Requirements Analysis in IDEF0 conventions.
A data mode, building on the activity model, defines entities, their attributes, and their relationships. IDEF1X, a methodology created to help design data, provides a structured notation and syntax consisting of: (1) a set of diagrams containing entities, their attributes, and their relationships; (2) a glossary which defines the entities and attributes; and (3) business statements, which are detailed, written descriptions of the way in which data relate to other data. The C2 Core Data Model uses IDEF1X notation and modeling conventions to describe the core data required across all C2 sub-functional areas and presents a common approach to describing tactical C2 information. It consists of 165 entities and more than 800 attributes. These attributes, together with their definitions and associated metadata (data describing data elements), will form the basis for submission of candidate standard data elements to the DOD data standardization program. The C2 Core Data Model is the foundation for the development of standard data elements and, as necessary, will be extended to reflect data requirements specific to battlefield digitization.
Technical, procedural, and methodological conventions used to establish standard data elements, including metadata and modeling products as documented in DOD 8320.1 series guidance (Standard Data Elements for Automated Information Systems (AIS) Design and Development).
Data dictionary or other repository for standard data elements.

The VMF provides a common standard for formatting bit oriented messages. Existing messages are being translated into VMF formats and where necessary, new messages and/or new data elements are being defined. The Technical Interface Design Plan (TIDP) has identified a set of VMF messages focusing on brigade and below digitization requirements outlined in the Operational Requirements Analysis for brigade and below. The TIDP has been submitted to the Joint Interoperability Engineering Organization for Joint approval.

A recent DOD policy designates the US agreed Link-16 data link as the DOD primary data link for all C2I and weapon systems applications, unless an exception is granted. A C3I Tactical Data Link Management Plan will be developed to enhance operational effectiveness of Joint and Combined forces; wherever possible, permit standardization of tactical C3I data links on the battlefield; and detail a migration strategy for data link waveforms and fixed and variable format message standards. The Army actively supports efforts of the Working Group to develop the C3I data link migration strategy and plan and is initiating assessments to determine the requirements for and to assess the feasibility of Link 16/VMF interfaces.

Near-Term Considerations for Battlefield Digitization

To date, lower-echelon information systems have been primarily messaging and display systems. As the evolving systems incorporate database capabilities and require seamless interoperability with command and control systems at brigade and above, there is a more pressing need for data standardization across the various battlefield information systems. The data element standardization efforts and the message standardization efforts will be integrated. Where standard data elements have been defined in the C2 Core Data Model, these will be used. As necessary, the C2 Core Data Model will be extended to accommodate additional data elements and relationships. The ultimate goal is to eliminate the need for message sets, such as character oriented USMTF, and do direct data base to data base transfers.

4.3.3.4 Human Computer Interface (HCI) Standard

Standardizing the HCI across application software to attain a user interface that presents a common appearance and behavior across Army systems requires a common set of HCI standards and a common approach to implementing them. The Army is developing guidance that will assure a common approach for systems that will be used to digitize the battlefield. This guidance will be contained in documents called "style guides."

Volume 8 of the DOD TAFIM contains the DOD HCI Style Guide. This style guide sets the basic standards for graphical HCIs for Army systems. However, the DOD Style guide is a general document that outlines the basic display standardization needs of the community. It does not therefore achieve the level of detail needed for truly interoperable systems that exhibit a common look and feel on the battlefield.

The User Interface Specifications for the GCCS define the "look and feel" of 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 provide detail 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.

The DOD HCI and AGCCS HCI Style Guides will set the basic interface standards for the ATCCS, FBCB2 and the other embedded system developers. However, in both of these style guides, the primary method of user interaction is through a graphical user interface (GUI). This standards profile also makes provision for an alternative mode of interaction, a character user interface (CUI) Applications that present graphical displays, such as maps, are accessible only through a GUI, however, applications that present non-graphical information, such as text, or tables of figures, can be accessed through either a graphical or character user interface. The benefit of a CUI is that it requires far less bandwidth. Since the bandwidth available to many battlefield users is very constrained, a CUI is necessary to provide them access to their essential applications.

4.4 Assessment Strategy

Continuous Evaluation Effort

Validation of the warfighting capability of forces equipped with digitization technologies can best be characterized as a continuous evaluation effort. This effort will be based primarily on timely and cost-effective assessments of validation and training exercises such as the major AWEs. The validation will also include the implementation of training programs and strategies, results from related operational and developmental tests, and the outcomes of modeling and simulation (M/S) efforts.

Early Identification of Problems

The ability to capitalize on opportunities for early testing, experimentation, and simulation in the Battle Lab environment will result in the early identification of problems and required solutions. From the beginning, the Army Analytic and Test and Evaluation communities will be involved in assessing the effectiveness of technologies, doctrine, procedures, and force structures. Operational Performance Objectives (OPO), Measures of Effectiveness (MOE) and Measures of Performance (MOP) are established within the Experimentation Master Plan (EXMP) to assess specific changes and track their effect over time. The measures of effectiveness focus on increases in force lethality, survivability, and tempo. OPO, MOE, and MOP will be validated by the Director, Joint Venture.

Integrated Experiments and Modeling & Simulation

The assessment is structured around a "rolling baseline" concept that integrates the experimentation and modeling and simulation efforts. M/S sponsored by the Louisiana Maneuvers Task Force (LAMTF) will be conducted by the TRADOC Analysis Command (TRAC) initially to establish thresholds for baseline MOEs using existing force structures and communications capabilities. The same model will be run using expected digital capabilities to establish initial MOE thresholds for a digitized force. Cumulative data from digitization experiments and exercises (ATDs, Advanced Concepts Technology Demonstrations (ATCD, BLWEs) will be used to calibrate the models. Once calibrated with this live exercise or experiment data, the models will be re-run to assess potential impacts of digitization on the force measures of effectiveness as well as looking at the synergistic effects between and within the BOS. Using calibrated M/S permits further examination of impacts caused by organizational changes versus those caused by digitization. It also supports an assessment of the effects of different employment concepts with the same systems, as well as varying scenarios and force structures. The major AWEs will be used to validate the M/S thresholds established for lethality, survivability, and lethality measures of effectiveness.

Cyclic Process

This cyclic process supports the ADO's evaluation of the value-added by digitization, while minimizing the need for large scale, costly field experiments and exercises. The TRADOC-led Analysis Experimentation Planning Group (AEPG) will be the forum to facilitate the close coordination and cooperation needed among the M/S, system developer and test communities.

4.4.1 Experimentation and Evaluation

EXMP

An initial EXMP, prepared by PEO-CCS, will guide the experiments for assessment of the applique through Brigade Task Force XXI. The Army's Independent Evaluators, Army Materiel Systems Analysis Activity (AMSAA) and Operational Test and Evaluation Command (OPTEC), in conjunction with the ADO, materiel developer, TRADOC, AMC (CECOM), and Forces Command (FORSCOM) will optimize evaluation support of the battlefield digitization effort through the EXMP.

Experimentation and testing of digital information technology will be designed to determine adequacy of requirements, to identify the best use of new capabilities, and to collect data necessary to provide credible evaluations in support of procurement decisions. Continuous evaluation through scheduled constructive, virtual, and live experiments and other separate, operational, and technical testing will verify equipment progress toward meeting mission needs and performance objectives.

AWEs and BLWEs

The Army, through its Joint Venture Campaign Plan, will conduct a series of experiments to demonstrate improvements in force effectiveness as a result of fielding digital-information technologies, and by changing organizational designs and tactics, techniques, functions, and procedures. These experiments, called AWEs and BLWEs, will be designed to provide insights and yield data to both address operational force effectiveness and system-level performance issues. Applique and ATD equipment will be examined in these experiments to establish an early understanding of their warfighting potential. Each experiment will build upon the results of previous experiments, creating the "rolling baseline" assessment to measure force effectiveness increases.

Opportunities for data collection will occur in the course of fielding battlefield digitization equipment to the Joint Venture experimentation force (EXFOR). For example, during scheduled individual, crew, and collective training on the operation and use of the equipment, data will be obtained on both system performance and suitability. By taking advantage of these opportunities, the need for separate operational and technical tests should be diminished.

Five Classes of Experiments

In general, there will be five classes of experimentation and testing conducted to support the development and evaluation processes:

1) Integration Laboratory Certification-Preliminary examination of prototype hardware and software to verify ability to perform critical functions and meet interoperability requirements. Lead is AMC (CECOM) with participation from ADO, AMC (AMSAA), TRADOC and OPTEC.

2) BLWE-Virtual, constructive, or field event to examine new equipment, processes, and force design issues. BLWEs should provide significant opportunities for rigorous data collection to satisfy evaluation requirements. Lead is TRADOC with participation from OPTEC, ADO and AMC's (AMSAA and CECOM).

3) AWE-Major event conducted in a tactically rigorous environment to confirm experimental hypotheses regarding increases in warfighting capability. System-performance data collection during these events will be limited to minimize interference with training, realism, and other objectives. Lead is TRADOC with participation from OPTEC, ADO and AMC's (AMSAA and CECOM).

4) Technical Test (TT)-Event conducted to confirm that critical technical parameters and contractual specifications have been met, and also to examine system performance in especially stressful and controlled environments. These events will be conducted as necessary after successful Integration Laboratory certification and in parallel/coordination with BLWEs and Operational Tests. Lead is AMC (AMSAA) with participation from OPTEC, ADO, TRADOC and AMC (CECOM).

5) Operational Test (OT)-Event conducted to obtain data on total system performance when employed by representative soldiers in an operational environment. OT will be conducted as necessary to fill "data voids" in order to provide credible operational assessments for procurement and fielding decisions. Lead is OPTEC with participation from TRADOC, ADO, and AMC's (AMSAA and CECOM).

4.4.2 Modeling and Simulation (M/S) Strategy

Models

Models will be used throughout the digitization program to evaluate Operational and Technical Architectures, alternative technologies, interoperability, and force effectiveness issues. These models and simulations are categorized as either constructive, virtual, or live. Combinations of these provide the most complete environment possible in which to examine digitization.

Constructive models and simulations require little human interaction during operation. A majority of system performance, network assessment, and force-on-force combat models fall into this category. Virtual simulations use manned simulators sharing "real" world computer generated images that require extensive interaction by participants. Live simulations are categorized as experiments, training exercises, demonstrations, and tests that take place in a field-like environment.

An objective simulation environment is needed to support digitization efforts. This objective environment integrates system performance models, constructive models, and virtual simulations through the use of distributed interactive simulation (DIS). Common representations of system and technology performance, architecture designs, network components, and environmental impacts (e.g., electronic warfare) across all simulation categories will provide a "seamless" evaluation environment. Data requirements to properly calibrate the models must be clearly identified by the M/S organization and the data collected by the test agency. AMC (CECOM and STRICOM) will orchestrate and coordinate modeling and simulation efforts to insure a logical flow of simulation experiments that are supported by meaningful network assessment, system performance and DIS.

Simulation
All models and simulations used to support the ADO assessment of digital communications are to be Verified and Validated (V&V) by the sponsoring/developing organization, as well as accredited by the using organization. This requirement for V&V includes combinations of separate models, such as a digital radio model interacting with simulators in DIS.

Four Classes of M/S

In general, there will be four classes of M/S to support the development and assessment processes:

1) The simulations that are part of the DIL at AMC (CECOM)'s Research Development and Engineering Center (RDEC) will be used to support system engineering and integration efforts. The DIL will permit hardware and software developers to test products in a realistic communications environment early in their design to enable redirecting development or eliminating inappropriate concepts. This capability supports the ADO plan for decreased system development time and evaluation of future technology insertions. The AIN, a critical aspect of the DIL, will be used to help resolve interoperability issues.

2) AMC (CECOM RDEC) and the TRADOC Battle Labs will use DIS, such as Simulation Networking (SIMNET) and Battlefield Distributed Simulation-Developmental (BDS-D), in conjunction with system and network performance models to the maximum extent possible to answer questions relating to the man-machine interface, use of digitally provided information, concepts of employment, acquisition, and fielding.

3) Network assessment models and simulations will be used to examine both the Technical and Operational Communications Architectures. The TRADOC's BCBL, will use Operational Architecture models to investigate operational considerations over a multiple number of communications networks simultaneously. These models assess information flow and communications means, development and portrayal of mission thread paths, mission timelines and variables, insights of system integration and interoperability, and identification of architecture redundancies. These models will examine and develop techniques for insertion of new protocols or modifications to existing transmission facilities and systems

4) Constructive force-on-force M/S is a primary factor in the "rolling baseline" assessment concept proposed for Force XXI and described in paragraph 4.3 in the overall Assessment Strategy. This cyclic modeling process supports the ADO's evaluation of the value-added by digitization, while minimizing the need for large scale, costly field experiments and exercises.

4.4.3 Battle Labs

The TRADOC Battle Labs play key roles in refining the requirements for digitization and in defining the operational concepts and doctrine that will allow the Army to optimize the combat application of these technologies. The Battle Labs participate throughout the development process developing and validating digitization requirements, providing technology assessments and evaluating alternative tactics, techniques, and procedures. Battle Labs work closely with the operational test community to develop suitable test scenarios. Battle Labs conduct experiments and sponsor new technology into exercises as part of their requirements development process. Battle Labs are key participants in defining Force XXI objective requirements through experimentation in ATDs, AWEs, and exercises such as Prairie Warrior and Mobile Strike Force.

NEWSLETTER

Join the GlobalSecurity.org mailing list

Military

Army Digitization Master Plan (ADMP)

CHAPTER 4 - DIGITIZATION EXECUTION