A Nontraditional Approach to Technology Development

Wolfpack Deliverable Competition Sensitive

Wolfpack Enterprise Competition Sensitive Exponent Booz Allen Hamilton The Wexford Group Charles River Analytics Hamilton Sundstrand Wyle Laboratories

Wolfpack Deliverable Title: Program Summary Report SLIN: 2CP Due Date: 25 April 2003 Agreement No: DAAD16-02-9-0002 ALIN: 0001 Wolfpack Contact: Gary Riccio (508) 652-8576 [email protected] Disclosure Notice: Due to the competitive nature of Objective Force Warrior Phase I (Concept and Technology Development), requests for this product shall be referred to the Technology Program Manager, Natick Soldier Center, Natick, Massachusetts, 01760-5011.

ii


Contents Page

Exhibits v

Acronyms and Abbreviations vi

1. Introduction 1

2. Wolfpack Processes: Concurrent Engineering 2 2.1 Coordination Among Processes and Products 3

2.1.1 Wolfpack Organization Structure 3

2.2 Scientific Approach to Technology Development 8 2.2.1 Coordinating Events and Convergent Processes 9

2.3 Summary of Systems Engineering Processes 9

3. Wolfpack Products: Summaries and Interrelationships 10 3.1 Operational Concept 10

3.1.1 Link to Requirements Management Process 10

3.1.2 2AA-2AC Executive Summary 12

3.1.3 2AD-2AF Executive Summary 12

3.1.4 2BQ-2BS Executive Summary 13

3.1.5 Link to Other Groups of Deliverables 14

3.2 Technology Concept 14 3.2.1 Link to Architecture/Design/Integration Processes 14

3.2.2 2AP-2AR Executive Summary 15

3.2.3 2BT-2BV Executive Summary 16

3.2.4 2AV-2AX Executive Summary 16

3.2.5 2BW-2BY Executive Summary 17


3.3 Technology Identification 18 3.3.1 Link to COTS-GOTS/Assess and Select Processes 18

3.3.2 2CF, 2BP Executive Summary 19

3.3.3 2BN1-2BN3 Executive Summary 20


iii


3.4 Interfaces and Interoperability 21 3.4.1 Link to Requirements Management Process 21

3.4.2 2AU, 2CE Executive Summary 23

3.4.3 2AY-2AZ Executive Summary 23

3.4.4 2AS-2AT Executive Summary 24


3.5 Life Cycle Analysis 31 3.5.1 Link to Program and Process Management Process 31

3.5.2 2BK-2BK1 Executive Summary 31

3.5.3 2BC-2BD Executive Summary 33


3.6 Quick Look Events 35 3.6.1 Link to Design and Implementation 35

3.6.2 2BN7, 2BB4, 2BA3 Executive Summary 36



3.6.5 2BN4, 2BB1, 2BA Executive Summary 42






3.7 Systems Engineering 58 3.7.1 Link to Program and Process Management Process 58

3.7.2 2AJ-2AK Executive Summary 59

3.7.3 2BL-2BN Executive Summary 60

3.7.4 2BI-2BJ Executive Summary 60

3.7.5 2CA-2CC Executive Summary 61


3.8 Meetings with OFW TPO 62 3.8.1 Link to Program and Process Management Process 62

iv


3.8.2 2AG-2AI Executive Summary 63

3.8.3 2BG-2BH Executive Summary 64


3.9 Program Level Deliverables 64 3.9.1 Link to Design and Implementation Process 64

3.9.2 2BE-2BZ Executive Summary 65

3.9.3 2BF, 2AL Executive Summary 67

3.9.4 2BB Executive Summary 68

3.9.5 2CG-2CN Executive Summary 68


4. Conclusion 69 4.1 Core Soldier Configuration 70 4.2 Infantry OFW Soldier 71

4.2.1 Infantry Squad Configurations 72

4.3 Maneuver Arms Aircrew 76 4.4 Mounted Crew 78 4.5 FCS Interface 79

4.5.1 Communications with FCS Assets 79

4.5.2 Physical interface with FCS Assets 80

4.5.3 Leveraging of FCS Assets with Respect to OFW Squad Equipage 80

4.6 Tradeoff Analysis, SWaP, and Cost 81

v


Exhibits Page

Exhibit 1. OFW Phase I Deliverables Referred to in this Document 2

Exhibit 2. Matrix Organization of Wolfpack in Phase I 3

Exhibit 3. Grouping of Deliverables into Working Groups, Tasks, and Subtasks 5

Exhibit 4. Responsibilities of Leaders for Coordination 8

Exhibit 5. Spiral Development Process 10

Exhibit 6. Operational Concept Link to Requirements Management Process 11

Exhibit 7. Technology Concept Link to Design Process 15

Exhibit 8. Technology Identification Link to Assess and Select Process 19

Exhibit 9. Interfaces and Interoperability Link to Requirements Management 22

Exhibit 10. Programmatic, Technical, and Operational OFW-FCS Integration Risks 30

Exhibit 11. Life Cycle Analysis Link to Program Management 31

Exhibit 12. Quick Look Events Link to Design and Implementation 36

Exhibit 13. Sensor and Sensing Alternatives 41

Exhibit 14. Connectivity Ranges 44

Exhibit 15. Systems Engineering Link to Program Management 59

Exhibit 16. Meetings with OFW TPO Link to Program Management 63

Exhibit 17. Program Level Deliverables Link to Design and Implementation Process 65

Exhibit 18. Core Soldier Configuration with Projected 2006 Weight and Power 71

Exhibit 19. OFW UA Rifle Squad Configuration (Notional) 73

Exhibit 20. OFW UA Weapons Squad (Notional) 74

Exhibit 21. OFW UA Command Node Security Squad (Notional) 75

Exhibit 22. OFW UA Recce Squad (Notional) 76

vi


Acronyms and Abbreviations

A&A Analysis and Assessment AMSAA U.S. Army Material Systems Analysis Activities ARV Armed Robotic Vehicle ASB Army Science Board CAI Contractor Acquired Items CAIV Cost as an Independent Variable CASRED Casualty Reduction model (Natick Soldier Center) CAT Combat Applications Team CBRN Chemical, Biological, Radiological, and Nuclear CCC Close Combat Chassis CECOM Communications-Electronics Command COP Common Operating Picture COTS Commercial Off-The-Shelf CPR Cost Performance Report CQB Close Quarters Battle CROP Common Relevant Operating Picture CS/CSS Combat Support/Combat Service Support CTD Concept and Technology Development DARPA Defense Advanced Research Projects Agency DBBL Dismounted Battlespace Battle Lab DMFC Direct Methanol Fuel Cell DNCIE Dynamic Networking and Common Interface Exploration DoD Department of Defense DOTMLPF Doctrine, Organizations, Training, Materiel, Leadership and

Education, Personnel, and Facilities DPO Deputy Program Manager DTED Digital Terrain Elevation Data EA Evolutionary Acquisition ENW Enhanced Network Waveform EPAT Energy and Power Assessment Tool EV Earned Value EVMS Earned Value Management System FCS Future Combat Systems FoS Family of Systems FOV Field of View FSB Forward Support Battalion FSR Fisheye State Routing GFI Government Furnished Items GOTS Government Off-The-Shelf HP&P Human Perception and Performance HSI Human System Interface I2 Image Intensification ICD Interface Control Drawing

vii

Wolfpack Enterprise Competition Sensitive

Exponent Booz Allen Hamilton The Wexford Group Charles River Analytics Hamilton Sundstrand Wyle Laboratories

ICWG Interface Control Working Group IDE Integrated Data Environment IETE Internet Engineering Task Force IMP Integrated Master Plan IMS Integrated Master Schedule IOR Integrated Open Review IPPD Integrated Product and Process Development IPR In-Process Review ISS Information Systems Services IUSS Integrated Unit Simulation System JCATS Joint Conflict and Tactical Simulation JEM JTRS-Enhanced MBTR JTA-A Joint Technical Architecture Army JTRS Joint Tactical Radio System KIA Killed In Action LCC Life Cycle Cost LCCE Life Cycle Cost Estimate LCCUS Life Cycle Capability Upgrade Strategy LCCUIS Life Cycle Capability Upgrade Information System LLAMA Load Leveraging Assist-Modular and Assault LSI Lead Systems Integrator LTI Lead Technology Integrator LWIR Long Wave Infrared KPP Key Performance Parameter K&SS Knowledge and Smart Systems LCC Life Cycle Cost LER Loss Exchange Ratio M&S Modeling and Simulation MANTECH Manufacturing Technology MAPEX Map Exercise METT-TC Mission, Enemy, Terrain and Weather, Troops and Support, Time, and

Civil Considerations MoE Measure of Effectiveness MoP Measure of Performance MOS Military Occupational Specialty MOUT Military Operations in Urban Terrain MULE Multifunctional Utility/Logistics and Equipment NC/CSA Netted Communications/Collaborative Situational Awareness NCO Non-Commissioned Officer NIR Near Infrared NSC Natick Soldier Center OAV-L Organic Aerial Vehicle Light O&O Organization and Operation O&OC Operational and Organizational Concept ODS Ozone Depleting Substance

viii

Wolfpack Enterprise Competition Sensitive

Exponent Booz Allen Hamilton The Wexford Group Charles River Analytics Hamilton Sundstrand Wyle Laboratories

OF Objective Force OFW Objective Force Warrior ORD Operational Requirements Document PAN Personal Area Network PEO Program Executive Office PM Program Manager PSM Physiological Status Monitoring QLL Quick Look Leader R&D Research and Development RF Radio Frequency S&T Science and Technology SA Situational Awareness SaaS Soldier as a System SE Systems Engineering SE/CM Systems Engineering/Capability Model SEP Soldier Enhancement Program SDD System Development and Demonstration SID Soldier Interface Device SLICE Soldier-Level Integrated Communications Environment SLIN Sub-Line Item Number SMA-OSCR Supply Management Army Operating and Support Cost Reduction SME Subject Matter Expert SOO Statement of Objectives SORC Statement of Required Capabilities SoS System of Systems SoSA System of Systems Architecture SUGV Small Unmanned Ground Vehicle SWaP Size, Weight, and Power TCL Technology Category Leader TI Technology Insertion TIM Technical Interchange Meeting TOC Total Operating Cost TPO Technology Program Office TRADOC U.S. Army Training and Doctrine Command TRL Technical Readiness Level TSM-S TRADOC System Manager Soldier TTP Tactics, Techniques, and Procedures UA Unit of Action UAV Unmanned Aerial Vehicle UE Unit of Employment UGV Unmanned Ground Vehicle UHF Ultra High Frequency USARIEM U.S. Army Research Institute of Environmental Medicine V&V Verification and Validation WBS Work Breakdown Structure

ix


WFOV Wide Field of View WGL Working Group Leader WIA Wounded in Action WIN-T Warrior Information Network Tactical WME Weapons, Munitions, and Explosives Wolfpack Wolfpack Enterprise WPM Wolfpack Program Manager


1

1. Introduction The goal of the Objective Force Warrior (OFW) program is to identify, develop, integrate, and demonstrate technologies for systems to a) equip individual Objective Force soldiers and leaders, and b) enable Objective Force small units to be organized, trained, led, manned, and supported to operate as a system of systems and family of systems. This document provides an overall summary of Wolfpacks OFW Phase I effort. Section 2 describes Wolfpacks organizational and concurrent engineering approach to Phase I. Section 3 presents descriptions of each of the Wolfpack OFW Phase I deliverables and the relationships among them. It is organized in groups of related deliverables so that these relationships, both within and among groups, can be more easily explained. Section 4 then concludes the document with a description of the conceptual output of Wolpacks OFW Phase I concurrent engineering activities. The Wolfpack OFW Phase I deliverables referred to in this document are as follows:

SLIN Subject or Title

2AA-2AC System of Systems Concept

2AD-2AF Organizational and Operational Concept

2BQ-2BS Operational Architecture

2AP-2AR System of Systems Architecture

2BT-2BV Systems Architecture

2AV-2AX Netted Communications/Collaborative Situational Awareness Architecture

2BW-2BY Technical Architecture

Technology Investment Review 2CF, 2BP Tradeoff Assessment

Technology Survey Document 2BN1-2BN3 Technology Assessment Documents #1, #2

2AU, 2CE FCS Interface Requirements FCS Program Review

2AY-2AZ Evaluation of NC/CSA Interoperability with FCS Evaluation of WIN-T and JTRS for OFW Needs

2AS-2AT Interface Control Working Groups

2BK-2BK1 Life Cycle Cost Containment Strategy

2BC-2BD Life Cycle Capability Upgrade Strategy

2BN7, 2BB4, 2BA3 Human Perception and Performance Prototype Human Perception and Performance Experimentation Human Perception and Performance M&S


2

2BN6, 2BB3, 2BA2 Knowledge and Smart Systems Prototype Knowledge and Smart Systems Experimentation Knowledge and Smart Systems M&S

2BN5, 2BB2, 2BA1 Sensors and Sensing Prototype Sensors and Sensing Experimentation Sensors and Sensing M&S

2BN4, 2BB1, 2BA Netted Communications Prototype Netted Communications Experimentation Netted Communications M&S

2BN8, 2BB5, 2BA4 Protection Prototype Protection Experimentation Protection M&S

2BN9, 2BB6, 2BA5 Load Carrying Prototype Load Carrying Experimentation Load Carrying M&S

2BN12, 2BB8, 2BA7 Weapons, Munitions, and Explosives Prototype Weapons, Munitions, and Explosives Experimentation Weapons, Munitions, and Explosives M&S

2BN11, 2BB7, 2BA6 Energy and Power Prototype Energy and Power Experimentation Energy and Power M&S

2AJ-2AK Baseline System Level Requirements

2BL-2BN Integrated Master Plan

2BI-2BJ Risk Management Strategy Risk Management Plan

2CA-2CC Integrated Data Environment

2AG-2AI Integrated Process/Product Team Meetings

2BG-2BH Integrated Open Review and In-Process Review

2BE-2BZ Videos, Diagrams, and Pictures Mockups

2BF, 2AL Performance Metrics Concept and Technology Development Exit Criteria

2BB Integrated Evaluation Document

2CG-2CN Monthly Technical and Financial Status Reports

Exhibit 1. OFW Phase I Deliverables Referred to in this Document 2. Wolfpack Processes: Concurrent Engineering The challenge of Objective Force Warrior (OFW) effort in Phase I has been to develop a programmatically, operationally, and technically well-grounded concept for an individual and small unit System of Systems (SoS) for which there is no precedent. A spiral development approach is required by such ambitious objectives. The fact that all this was


3

required to be completed in eight months demanded a method of operation and organization as innovative as the resulting design concept. The only solution was concurrent engineering; that is, to conduct processes in parallel that are logically sequential in a spiral development approach and to do so without sacrificing the logical dependence among tasks within the spiral. The following sections describe the Wolfpack Enterprises (Wolfpacks) operational and organizational implementation of concurrent engineering for Phase I of OFW.

2.1 Coordination Among Processes and Products

2.1.1 Wolfpack Organization Structure

Wolfpack is not organized in a strict hierarchy. Wolfpack personnel are matrixed to groups (teams) to achieve cross-fertilization among tasks, to facilitate coordination across concurrent activities, and to ensure that self-organization of the various groups is convergent rather than divergent. An organizational chart is provided as Exhibit 2 to show the distributed and decentralized management structure in the OFW project (note that it generally is difficult if not impossible to represent a matrixed organization in a form that adheres to organizational chart conventions).

Exhibit 2. Matrix Organization of Wolfpack in Phase I Rows correspond to tasks, and columns correspond to technical categories or areas

Operations

Prog. Review

Ops Concept

Tech ID

SoSA

Life Cycle

Proto.- Eval.

Proto.- Eval.

Proto.- Eval.

Proto.- Eval.

Systems Eng.

Administr.

Prog. Manag

WMEPowerEnergy

Load Carry

Soldier Protect

SensorNettedComm

Perfor. Aids

AITech Tasks

Operations

Prog. Review

Ops Concept

Tech ID

SoSA

Life Cycle

Proto.- Eval.

Proto.- Eval.

Proto.- Eval.

Proto.- Eval.

Systems Eng.

Administr.

Prog. Manag

WMEPowerEnergy

Load Carry

Soldier Protect

SensorNettedComm

Perfor. Aids

AITech Tasks

DPM

DPM

TechnologyDevelopment

ConceptDevelopment

IntegratedEvaluation

Quick Look 2 Quick Look 3Quick Look 1

WPMWPM

Quick Looks

Working Groups


4

The distributed and decentralized management structure within Wolfpack has tasks and technology categories as its fundamental units of (self) organization. This is the level at which the most important design decisions are made and at which the most significant innovations occur. Subordinate and superordinate levels of organization provide the necessary mechanisms of coordination among tasks and tech categories.

Tasks and associated groups (teams) have been organized around groups of SLINs (deliverables) derived from the Statement of Objectives (SOO) in the OFW Solicitation. Many products of these tasks are delivered in multiple versions (e.g., initial, interim, final) to maximize the Governments visibility into and opportunities for influence on Wolfpacks spiral development process. Consistent with the Phase I proposal, tasks are grouped into working groups associated with concept development, technology development, and integrated evaluation. The Wolfpack organization thus imposes a structure to the otherwise overwhelming number and variety of deliverables. This structure is reflected in Exhibit 3.


5

Exhibit 3. Grouping of Deliverables into Working Groups, Tasks, and Subtasks


6

2.1.1.1 Roles and Responsibilities of Leaders

The matrix organization of Wolfpack is manifested in a number of groups that cut across tasks; that is, that have an influence on each task and that share personnel with task groups. Key personnel in these cross-cutting groups are responsible for ensuring coordination among task groups and convergence of task activities, decisions, and directions. Responsibilities of the key personnel are described below and depicted graphically in Exhibit 4.

2.1.1.2 SLIN Leaders

Primary responsibility for deliverables Coordinate contributions of all individuals working on deliverable Coordinate and integrate with other SLIN Leaders in task group.

2.1.1.3 Company Representatives

Primary responsibility for company contributions Primary responsibility for subcontract coordination.

2.1.1.4 Task Leaders

Primary responsibility for managing teams Primary responsibility for coordination and integration of SLINs within tasks Report progress to Wolfpack Administrator and Exponent Task Managers Coordinate with other task leaders.

2.1.1.5 Technology Category Leaders

Ensure coherent approach to technology development Coordinate and integrate across working groups.

2.1.1.6 Technology Category Representatives

Coordinate and integrate tasks with respect to technology categories Report on progress to Working Group Leaders (WGLs) Coordinate and integrate across working groups Integrate among technology categories within working group.


7

2.1.1.7 Quick Look Leaders

Contribute to integrated evaluation Manage Quick Look (QL) events Report on progress to Wolfpack Program Manager (WPM) and Deputy Program

Managers (DPMs)

Coordinate with other QL Leaders (QLLs). 2.1.1.8 Working Group Leaders

Provide Government representatives visibility and opportunity for influence Contribute to packaging of deliverables Contribute to QL events Coordination among tasks Report on progress to program managers (WPM and DPMs).

2.1.1.9 Deputy Program Managers

Coordinate with WPM and other DPM Provide Government representatives visibility and opportunity for influence.

2.1.1.10 Wolfpack Program Manager

Coordinate with DPMs Coordinate with systems engineering team Coordinate with Wolfpack Administrator Provide Government representatives visibility and opportunity for influence.


8

Exhibit 4. Responsibilities of Leaders for Coordination

2.2 Scientific Approach to Technology Development

A key feature of Wolfpacks methodology in Phase I has been to foster the introduction and coexistence of multiple, even competing, perspectives. This commitment was explicit at the outset (e.g., at the Phase I kick-off meeting) and re-emphasized throughout Phase I. We believe this diversity is at the heart of a truly creative environment. Beyond this, there are two other essential reasons to foster diversity within our approach.

Diversity naturally results from a loose coupling between distributed and decentralized teams. Concurrent engineering during the concept phase of technology development requires tolerance of diversity and temporary divergence of concurrent processes. Wolfpack leaders have been responsible for coordinating the work of geographically separated teams working in parallel, but only intermittently. Periods of time on the order of weeks (many weeks in some cases) for teams working in relative isolation were required to mature ideas (i.e., to make unfettered progress) before there could be efficient and productive coordination among teams.

Both diversity and flexibility are required by our scientific approach to technology development. A scientific approach demands the ability to follow the creative process


9

wherever it leads and a tolerance of competing perspectives that help define where the process must lead. Being honest brokers would mean little without such a process. The scientific process also demands visibility into the competition of ideas and opportunities for influence on the assessment and resolution of this competition. Such open debate has been the hallmark of Wolfpacks approach in Phase I.

2.2.1 Coordinating Events and Convergent Processes

Flexibility and diversity do not come without cost. In our approach, the license for this freedom of creativity comes from disciplined inflexibility in other areas, such as the schedule of milestones. Our operations schedule in particular provided both the discipline and opportunities for coordination required to achieve stability and convergence of our concurrent processes. The key milestones in our operations schedule were two Technology Search events (TSEs) and three Quick Looks (QLs) from month two through month five of Phase I. These events brought key personnel from our geographically distributed team together for extended face-to-face collaboration and decision making. Thinking was free to vary and diverge between events because of our assurance that there would be well-defined points in time (i.e., a series of events) in which issues would be resolved or at least in which processes would become convergent.

The influence of soldiers and user representatives on scientists and engineers, and vice versa, was greatest and most apparent at these events. This mutual influence and collaborative decision making was open to the Government. While openness was required by our approach and by our promises, it was possible because of our confidence that it would lead to impressive results. In other words, our approach allowed us to be confident about such results without knowing at the outset what the results would be. In exercising this approach in Phase I, we have demonstrated a way to reduce risk without prematurely eliminating uncertainty (e.g., through premature technology commitments). In fact, our entire approach is a methodology for technological risk management.

2.3 Summary of Systems Engineering Processes

The Wolfpack Systems Engineering (SE) process is described in detail in our Phase I proposal and in our Risk Management documents (SLIN 2BI and 2BJ). It provides the structure that permits efficient coordination of many complex activities and the discipline that documents our management of risk throughout the project. SE processes that populate our spiral development approach are depicted in Exhibit 5. Variations of this Exhibit are used throughout the document to describe how our SE process maps into our tasks and associated deliverables.


10

Exhibit 5. Spiral Development Process Wolfpack will elaborate and refine the overarching SE process for the spiral development appropriate for preliminary and detailed design (Phase II). The essential processes associated with concept, design/development, and verification/limited production will again be followed. The difference in Phase II will be that considerably more resources will be devoted to SE because much tighter coordination of concurrent processes will be required to achieve design milestones and to achieve integration of subassemblies. The SE team will be larger, more active in tracking the activity of various teams, and responsible for flow of information and constraints among teams.

3. Wolfpack Products: Summaries and Interrelationships

3.1 Operational Concept

3.1.1 Link to Requirements Management Process

The activities and conclusions of Task 2 have their most significant impact on the Requirements Management Process (Exhibit 6). Requirements are a crucial element of the OFW strategy and provide specific key operational parameters. Identification of requirements is essential because it defines the operational capabilities that must be met


11

through corresponding technology solutions. As a Science and Technology (S&T) effort, OFW is not developing requirements per se. The OFW effort does, however, provide a unique opportunity to develop a solid foundation for requirements that ultimately will be developed for this unique SoS. At the same time, concept development and systems design are well served by the concurrent development of a programmatic, operational, and technical foundation for requirements. Requirements Management is also addressed in Task 1 (Programmatic Review) and Task 10 (Systems Engineering) and in the associated deliverables.

Exhibit 6. Operational Concept Link to Requirements Management Process


12

3.1.2 2AA-2AC Executive Summary

3.1.2.1 System of Systems Concept

The Wolfpack OFW SoS concept documents are a series of three documents developed by Wolfpack for the Concept and Technology Development phase of the OFW effort to describe soldier and leader systems, SoS, and Family of Systems (FoS) concepts for application within the Land Warrior Program and other programs of the Objective Force.

The ultimate purpose of the Wolfpack OFW SoS concept document is to provide a robust and holistic conceptual description of the Doctrine, Organizations, Training, Materiel, Leadership and Education, Personnel, and Facilities (DOTMLPF) implications, and the operational capabilities and functions of Objective Force soldier and leader systems, SoS, and FoS, and to provide clear understanding of these concepts for the other elements of the OFW effort and to other Objective Force concepts and programs.

The SoS concept resulted from deliberations conducted using the DTOMLPF analysis approach taken by our Combat Applications Team (CAT) specifically during the assessment of the domains of doctrine and materiel. It became apparent to the CAT that if a holistic look at the small unit (squad/platoon) is taken, it makes tremendous sense to incorporate FoS and SoS into the Wolfpacks concept development. This thinking led to grouping capabilities into FoS and SoS that achieved a 20 improvement in combat effectiveness. The SoS concept directly influenced our Organizational and Operational Concepts (O&OC), Base Line System Level Requirements, and the System of Systems Architecture (SoSA).

3.1.3 2AD-2AF Executive Summary

3.1.3.1 Organizational and Operational Concept

The most difficult DOTMLPF problem of many confronting the OFW Concept and Technology Development effort is well characterized by the needs of those Objective Force soldiers who must seize and control key terrain by their direct action and close with and destroy enemy forces by close combat assaultmounted or dismounted. In particular, the most difficult and dramatically growing environment for the Objective Force, which future adversaries are likely to exploit, will be in urban terrain. Similarly complex terrain also exists in jungles and mountains. It is in these environments that achieving the ability to see first, act first, and finish decisively becomes most difficult, and in which dismounted assaults will predominate.

Under the current design of the first type of Unit of Action (UA), Objective Force solders most likely to conduct dismounted assault are Infantry. However, closely associated with the demands of assault and related individual and collective tasks are those Objective Force soldiers performing reconnaissance and close protection for command elements. Collectively this population of soldiers (approximately 32% under current designs) faces the most difficult physical challenges within the UA because (a) they will inherently


13

work away from their vehicles as opposed to those soldiers performing their primary tasks in the operation of FCS vehicles and equipment, and (b) they work without the protection inherently provided by combat platforms. Moreover, it is this population of soldiers under current UA operational concepts who will perform air assaults and other detached missions, which may take them long distances from the vehicular-based support structures provided by the FCS systems that will enable the UA.

Additionally bearing on the approach taken by Wolfpack concepts are the evolving conceptions of the Soldier as a System (SaaS). These concepts speak to the core capability of the Objective Force, its soldiers, and in particular appear to focus on the core or central demands leveraged on all soldiers of the Objective Force to be able to perform certain common tasks, regardless of specialization, and the equipment soldiers need to perform these common tasks. Common tasks and necessary equipment will certainly evolve with the introduction of technology; however, all soldiers in the UA will share some common expectations of performance, which logically necessitates some commonality of equipment.

3.1.4 2BQ-2BS Executive Summary

3.1.4.1 Operational Architecture

The Wolfpack OFW Operational Architecture document describes concepts and links DOTMLPF implications relevant to Operational Architecture products for Objective Force organizations, especially the UA and its subordinate formations, leaders, and soldiers. The Wolfpack OFW Operational Architecture document provides a foundation for development of Operational Architecture products, System Architectures, Technical Architectures, and SoSAs during Phases II and III of the OFW Program, and post-OFW development, by the OFW Lead Technology Integrator (LTI) and U.S. Army Training and Doctrine Command (TRADOC) schools and centers.

The Wolfpack OFW Operational Architecture document uses a variety of sources as its basis: (a) Wolfpacks OFW SoS and O&OC descriptions of OFW DOTMLPF implications; (b) concepts for OFW soldier and leader systems, SoS, and FoS from the Wolfpack OFW SoS Concept; and (c) O&OCs for Objective Force small units, soldiers, and leaders from the Wolfpack OFW O&OC. The inclusion of OFW DOTMLPF implications in the Wolfpack OFW Operational Architecture, SoS, and O&OC documents, and other Phase I deliverables, embraces the synergy of parallel advances to support the development and application of advanced soldier and other technologies.

Wolfpack has taken a technical approach in the OFW Operational Architecture document to guarantee traceability to Department of Defense (DoD) processes and documents. The approach pays particular attention to the processes that govern force and materiel development and ensures the S&T choices made early in the OFW Program are centered on the thinking of the DoD and the Army. Traceability of the evolution of thinking is important because DoD processes and documents will continue to evolve as the Army wrestles with the creation of the Objective Force. Put another way, traceability helps


14

ensure discipline and accuracy in evolving concepts and architectures in the OFW Program.

3.1.5 Link to Other Groups of Deliverables

3.1.5.1 Implications for the Technology Architectures

The Wolfpack OFW SoS Concept document provides the conceptual basis for the Wolfpack OFW O&OC, which serves as the infrastructure and architectural basis for the Wolfpack OFW Operational Architecture. When taken together the Wolfpack OFW O&OC and Operational Architecture must support execution of the OFW effort by providing requirements and implications for the OFW SoSA, Systems Architecture, and Technical Architecture.

Typically an Operational Architecture provides only information exchange requirements, interactions, tasks, interoperability tables, logical connectivity, and a description of the environment where an information system is to be operated. The OFW Operational Architecture also addresses all aspects and types of Objective Force individual Infantry soldier and leader systems, SoS, and FoS that may affect the OFW Operational Architecture and, hence the System Architecture. The System Architecture must characterize available technology and systems functionality in response to Operational Architecture and identify all of the kinds of systems and integration needed to achieve the desired operational capability.

3.1.5.2 Implications for Modeling and Simulation

For Phase I of the OFW Concept and Technology Development effort, the Wolfpack OFW SoS Concept document defines the operational relevance for the Wolfpack OFW Modeling and Simulation (M&S) effort addressing the Objective Force Infantry squad and platoon. The Wolfpack OFW SoS Concept document helps nurture the linkage between concept development and the spiral evolution of relevant technologies. It also provides a focus on answering the so what and what if questions relevant to a holistic approach to evaluating what would increase the combat potential of Objective Force Infantry squads and platoons.

3.2 Technology Concept

3.2.1 Link to Architecture/Design/Integration Processes

The Wolfpack Design and Architecture process occurs primarily in Task 4 and, to some extent, Task 3. These processes take the operational needs and available technologies and begins to fashion an integrated concept. Required standards drive the Technical Architecture, top level requirements and operational needs drive the SoS Architecture, and capability needs drive the System and NC/CSA Architectures (Exhibit 7).


15

Exhibit 7. Technology Concept Link to Design Process

3.2.2 2AP-2AR Executive Summary

3.2.2.1 System of Systems Architecture

The SoSA is intended to provide personnel involved in the OFW programfrom the soldier to the engineera means of understanding the interactions and relationships between systems based on a functional or operational perspective. This guide to relationships between technology areas/systems (e.g., power and Netted Communications [NC]) and operational functions illustrates how the technology areas overlap and how those relationships provide a synergistic increase in combat effectiveness.


16

These relationships are critical to understanding the ramifications of decisions and/or design changes, such as substitution of one weapon for a similar yet different one. This holistic view is necessary in order to prevent design, manufacture, and employment from adopting a myopic perspective on the overall system. More importantly, it provides a tool for tracing design changes and how those changes may affect other systems or operations.

3.2.3 2BT-2BV Executive Summary

3.2.3.1 Systems Architecture

Although it appears simple from the soldier/users perspective, the OFW system is very complex, with most of the machinery working behind the scenes to distribute and integrate SoS. The System Architecture document reflects this complexity and serves as a nexus of the other architecture documents.

The OFW System Architecture is described from the perspective of functionality subsystems. This accepts that technology components will overlap in terms of what subsystem they belong to, given that one component can serve many functions. Functionality subsystems include, but are not limited to, Information Systems Services (ISS), Human System Interface (HSI), Force Application, Load Carrying, Energy and Power (E&P), and Protection. By looking at the overall system from the functionality subsystem perspective, the architects can easily determine where subsystems overlap or potentially interfere, enabling the overall system to be streamlined and refined.

The main focus of the System Architecture is on the ISS and its parent Knowledge Management Subsystem (KMS), which includes (in essence) the software, sensors, and the recursive levels of NC. The KMS therefore is the interoperability point for all of the individual systems within the OFW SoS, as described in the SoSA document. The Technical Architecture document describes how these systems physically interconnect, and the Netted Communications/Collaborative Situational Awareness (NC/CSA) document describes how they interoperate in terms of data and communications. The System Architecture reflects the Wolfpacks parallel development process. It fuses the results of the operational concepts and technology QL assessments to produce a unified technology system blueprint.

3.2.4 2AV-2AX Executive Summary

3.2.4.1 Netted Communications/Collaborative Situational Awareness Architecture

The closely linked technology areas of NC and CSA are central to the Armys transformational vision of See First, Understand First, Act First, and Finish Decisively. Immediate understanding of current developments is made possible by the NC/CSA systems ability to provide exactly the right information, at exactly the right time, at the appropriate level of detail. The soldiers of tomorrow will experience neither cognitive


17

overload nor the fog of war, but will obtain the information that will best enable them to make decisions and complete missions successfully and safely. We believe that the ITT SLICE communications architecture and design methodology presented in the NC/CSA Architecture document strike the best balance between technical capabilities and operational need.

Situational Awareness (SA) is the soldiers integrated mental representation of what is happening. It involves bringing together disparate pieces of information from NC, any knowledge-based inferencing made available from the Knowledge Management Subsystem (KMSsee the System Architecture document [Final] [SLIN 2BV] for further discussion), and the OFW HSI (again, see SLIN 2BV for further discussion), as well as information that the soldier senses directlyi.e., that he sees, hears, touches, and smells in the real world. The NC/CSA architecture contains a detailed description of the projected implementation of a real-world system, including assessments of computation and storage locations, addressing schemes, and the publish/subscribe concept.

3.2.5 2BW-2BY Executive Summary

3.2.5.1 Technical Architecture

The Technical Architecture for the OFW is intended to provide a top-level definition of the OFW system partition and functional allocation. In the context of that top-level structure, the Technical Architecture provides a coherent set of governing standards that ensure that OFW subsystems and components operate effectively with each other, with the soldiers who rely on them, and with other elements of the Armys FCS. The Technical Architecture addresses all aspects of system functional integration including electronic and data, mechanical, thermal, and chemical interactions with the soldier and other systems.

The Technical Architecture document provides guidelines for the implementation of Wolfpacks OFW concept. The content ranges from open standards and general characteristics to module-by-module specific information. The Technical Architecture provides a framework for the formation of requirements that will evolve from the spiral development process. The OFW Technical Architecture is intended to foster flexibility, modularity, and freedom in design choices through the use of open standards for all of the elements that comprise the OFW SoS. The Technical Architecture is intended to provide the designer with a clear set of rules for achieving compatibility with other system elements and the system as a whole.


The SoSA exists at a very high level within the complete architectural description hierarchy. It seamlessly integrates the operational theories introduced in the O&OC Document (SLIN 2AF) and the detailed design of the Operational Architecture Document (SLIN 2BS) together with the technical subsystems introduced in the NC/CSA Architecture (SLIN 2AX) and SoSA Documents (SLIN 2AR). Input from the Life Cycle


18

Capability Upgrade Strategy Document (SLIN 2BD), Life Cycle Cost Containment Strategy Document (SLIN 2BK1), and Technology Identification Document (SLIN 2BN2) were also used in constructing the overall architecture.

The NC/CSA Architecture was greatly influenced by the parallel development of several other deliverables. Technical and program requirements generation was significantly influenced by the NC/CSA Interoperability Evaluation (SLIN 2AY), the results of the QLs as presented in Experimentation Document #1 (Netted Comms) (SLIN 2BB1) and the Prototype Document #1 (Netted Comms) (SLIN 2BN4). An understanding of the operational requirements and design issues was iteratively provided by the Operational Architecture (SLIN 2BS) and FoS/SoS Concept document (SLIN 2AC). The NC/CSA subsystem components were described in greater depth in the Technical Architecture (SLIN 2BY) and, when combined, fit cohesively into the frameworks provided by the System Architecture (SLIN 2BV) and SoSA (SLIN 2AR).

3.3 Technology Identification

3.3.1 Link to COTS-GOTS/Assess and Select Processes

The technology identification and assessment process occurs primarily in Task 3. Wolfpack has devoted significant resources to identification and assessment of Government and industry for technologies. We cast a wide net and then, through our Assess and Select process (Exhibit 8), evaluate the technologies against the need to find the best solutions. In an open collaborative process, Wolfpack considered almost 1,000 technologies and met with hundreds of vendors. Most of this occurred at TSEs and QLs at Fort Benning, which were open to the Government.


19

Exhibit 8. Technology Identification Link to Assess and Select Process

3.3.2 2CF, 2BP Executive Summary

3.3.2.1 Technology Investment Review (SLIN 2CF)

This document summarizes Wolfpacks analyses and recommendations to the OFW Technology Program Office (TPO) regarding technology investment decisions. The intent of this document is to (1) provide an assessment of the TPOs S&T portfolio in the context of OFW needs and goals, and (2) assist the TPO in prioritizing S&T efforts to meet OFW needs, thereby maximizing the return for the OFW soldier and small unit. Wolfpacks evaluation focuses on the technologies and programs presented at the OFW Open Review in October 2002, but expands beyond this set of technologies to ensure operational capabilities are properly addressed.


20

3.3.2.2 Tradeoff Assessment (SLIN 2BP)

This document describes the issues associated with and results of tradeoff analyses Wolfpack conducted to guide the development of the OFW Technical Architecture at both a systems and component level. High-level design decisions are discussed in the context of the 10 technology areas defined by the Government as necessary to support the OFW soldier and UA:

Organic lethality Networked fires Integrated protection NC CSA and information management Power sources Mobility Human performance and training Sustainment Sensors and displays.

Within the discussion of each of these technology areas, tradeoff analyses performed at the component level are presented for the technologies considered as having high impact (i.e., those considered critical enablers for achieving 20 increase in capability). To prioritize component technologies to be traded off, Wolfpack estimated the percentage contribution to the 20 increase in lethality by the technology areas identified as essential by the Army Science Boards (ASBs) FY2001 Summer Study.

3.3.3 2BN1-2BN3 Executive Summary

3.3.3.1 Technology Survey Document (SLIN 2BN1)

This document summarizes Wolfpacks first 2 months of activities for the Phase I technology search effort. The purpose of this document is twofold: (1) to provide information on the technologies and organizations identified to the date of publication, and (2) to describe the technology identification process to allow the Government or other parties to understand, repeat, and extend this type of activity for OFW or other research efforts that require technology mining to develop best-in-class technology solutions.

3.3.3.2 Technology Assessment Document #1 (SLIN 2BN2)

This document is the first of two Technology Assessment deliverables. It describes the assessment process and methodology used by Wolfpack to evaluate technologies


21

considered for inclusion into the Wolfpack OFW. The followup Technology Assessment Document #2 reports on the conclusions of the assessment process. Wolfpack has been performing these assessments since the inception of this contract and continued this process through its test bed QL experiments and M&S activities.

3.3.3.3 Technology Assessment Document #2 (SLIN 2BN3)

This document presents the results of Wolfpacks Phase I effort to survey and assess technologies for insertion into the OFW SoS. Specifically, the purpose of this effort and document is to evaluate the identified technologies according to a uniform set of criteria that can ultimately be used to perform tradeoffs between individual technologies. These criteria were presented in Wolfpacks Technology Assessment Document #1 (SLIN 2BN2).


SLIN 2CF was influenced by the following SLINs: 2BN1 (Technology Survey), 2BN2 (Technology Assessment #1), 2BN3 (Technology Assessment #2), 2BP (Tradeoff Assessment), 2BK, 2BK1 (Life Cycle Cost documents), 2BAX (M&S documents), and 2BBX (Experimentation documents).

SLIN 2BP was influenced by the following SLINs: 2BN1 (Technology Survey), 2BN2 (Technology Assessment #1), 2BN3 (Technology Assessment #2), 2CF (Technology Investment Review), 2BAx (M&S documents), 2BBx (Experimentation documents), 2BNx (Prototyping documents), and 2BK and 2BK1 (Life Cycle Cost documents).

SLIN 2BN1 was one of the early deliverables in the program. It heavily influenced the Technology Assessment #1 and #2, the Tradeoff Assessment, and the Technology Investment document.

SLIN 2BN2 was influenced only by SLINs: 2BN1 (Technology Survey) as it was one of the early deliverables in the program. However, it did heavily influence the Technology Assessment #2, Technology Investment, and Tradeoff Assessment documents.

SLIN 2BN3 was influenced by the following SLINs: 2BN1 (Technology Survey), 2BN2 (Technology Assessment #1), 2BK and 2BK1 (Life Cycle Cost documents) and 2AK (Baseline System Level Requirements).

3.4 Interfaces and Interoperability

3.4.1 Link to Requirements Management Process

An important part of the Requirements Management Process is conducting the programmatic due diligence that helps identify technical and operational constraints on system design imposed the needs to interoperate with systems developed in other programs. This programmatic due diligence occurs primarily in Task 1. As part of this


22

task, Wolfpack has gone through the FCS ORD, as well as our own CAT review, to develop our list of needed capabilities. In many cases these needs require interfacing with FCS and other programs. The Mission Needs and Requirements Development processes identified interface and interoperability needs with outside programs (Exhibit 9).

Exhibit 9. Interfaces and Interoperability Link to Requirements Management


23

3.4.2 2AU, 2CE Executive Summary

3.4.2.1 FCS Interface Requirements (SLIN 2AU)

This SLIN addressed FCS interface requirements on two levels: programmatic and engineering. Programmatic was designed to address coordination between OFW and FCS to eliminate any disconnects or oversights. Engineering addressed all system interfaces to include physical, human systems, mechanical, training, and electrical. Currently, there are expected to be 19 platforms with which OFW will have to interface to one degree or another. The interface requirements must look at all of these platforms and all of the soldiers across the UA, not just dismounted Infantry. The initiation of the Soldier-FCS Interface Control Working Group (ICWG) during Phase I is a great start at defining the interface requirements and ensuring that the programs work in parallel, integrating where required. Additionally, given that OFW will provide the soldier controller for the Multifunctional Utility/Logistics and Equipment (MULE), we have argued that OFW must have some influence on the FCS MULE design. Our intent would be to deliver a single interface control unit that would be capable of both Unmanned Ground Vehicle (UGV) and Unmanned Aerial Vehicle (UAV) control.

3.4.2.2 FCS Program Review (SLIN 2CE)

Wolfpack was tasked to support FCSs program review with the Government. This review did not take place as planned in November 2002. To our knowledge, the presentation package developed thus was not used. As part of this package, Wolfpack presented a summary of the FCS Operational Requirements Document (ORD), Infantry/Dismounted extracts, and LTI responses along with suggested OFW TPO comments on where OFW may be able to influence the FCS program. This document proved useful to Wolfpack as it went through its operational concept design as well as in the development of the baseline systems requirements document. Additionally, this review directly influenced the development of SLIN 2AU (FCS Interface Requirements).

3.4.3 2AY-2AZ Executive Summary

3.4.3.1 Evaluation of NC/CSA Interoperability with FCS (SLIN 2AY)

Wolfpack evaluated the NC and CSA concepts presently embedded in FCS to determine applicability to OFW. As we went through the program and identified high payoff areas that truly influenced getting to a 20 improvement in small unit capability, NC/CSA was rated as one of the most critical elements required to make this performance leap. Given it is such a critical component to the FCS and by default the OFW concept, NC/CSA became a key component to our Systems Architecture design and heavily influenced operational concepts. This element provided both the means to See First through the Common Relevant Operating Picture (CROP), but also allowed target engagements out of direct fire range by allowing connectivity to the Netted Fires System.


24

3.4.3.2 Evaluation of WIN-T and JTRS for OFW Needs (SLIN 2AZ)

The OFW program initiated a complex technology development and integration program to directly complement and support the FCS and Land Warrior programs to achieve Army Transformation objectives. A key facet of this integration identified early in our analysis is interoperability with both Warrior Information Network Tactical (WIN-T) and the Joint Tactical Radio System (JTRS). To properly evaluate the interoperability between OFW NC and WIN-T via FCS, it was necessary to explore two independent aspects: first, the technological interoperability of the systems, and second, the timing of the availability of each applicable constituent of the FCS and WIN-T, including JTRS. Where technological incompatibility or lack of capability was found, another method of satisfying the requirements was needed. This could take the form of defining another system solution, recommending changes, or revising the architecture of FCS, WIN-T, and/or JTRS. Where suitable technology was expected but the schedule projection showed that the technology would not be available in time to support the OFW schedule, either an interim measure (surrogate) or a different solution was proposed. After evaluation, we concluded that WIN-T and JTRS supply all required functionality needed to support the OFW program.

Program schedule interdependencies may well pose the greatest risk to FCS, JTRS, and WIN-T as well as to the OFW program. Mitigation of this risk can only come from mutual knowledge of schedule progress and prognosis, and this can only come from a concerted effort between programs. Specific interface designs can be expected to reflect an optimum distribution of functions between the various systems only if they are designed based on a concerted effort. Technical risk mitigation will be enhanced by inter-program communication and cooperation. OFW is aware of these risks, has developed a surrogate path to reduce risk, and is ready to actively work with JTRS to ensure program requirements are met.

3.4.4 2AS-2AT Executive Summary

3.4.4.1 Interface Control Working Groups

ICWGs represent a key element of the Spiral Development Process (refer to Exhibit 5) carried out by Wolfpack during Phase I of the OFW program. As described previously, two ICWGs were held during Phase I. The first, ICWG 1, was held at the Hamilton Sundstrand, Windsor Locks, Connecticut facility on 24 October 2002 early in this phase, while the second, ICWG 2, was held at the Hampton Inn in Natick, Massachusetts on 13 February 2003 near the end of the program phase.

These working group meetings were held to facilitate discussions between Wolfpack Technology Category Leads, Wolfpack, and NSC Systems Engineers and Program Managers on a variety of issues pertaining to OFW Architecture, System Designs, and System Integration. These meetings were used to identify and document the major system, subsystem, and component interfaces at the OFW Soldier, Small Unit, UA, or FCS levels and interfaces with other legacy systems such as Land Warrior Initial


25

Capability and System Integration. Additionally, these working groups facilitated discussions on individual technology choices and provided an opportunity for validation of these technology choices versus the identified OFW capabilities.

ICWG 1 attendees included all Wolfpack Technology Category Leaders (TCLs), Wolfpack and Natick Soldier Center (NSC) Systems Engineers, and Program Managers. Discussions included the following topics: Interface Control Drawing (ICD) family development process and ICD ownership, OFW system integration, small unit integration, FCS integration, core soldier systems development, and OFW capabilities. ICWG 2 attendees included all Wolfpack Technology Category Leads, Wolfpack and NSC Systems Engineers, and Program Managers. Discussions included the following topics: Overall OFW program status, Protection System Architecture, soldier and leader Personal Area Network (PAN) architectures, KMS overview, other technology choices, the UA interfaces, and an updated ICD list for Phase II.

A primary tool used for these working groups was a preliminary version of a family of ICDs. Upon completion of the OFW program design effort, this family of ICDs will be used to fully describe and control all system interfaces pertaining to the OFW SoS and FoS relationships mentioned above. These ICDs will address all electrical, mechanical, power, weight, volume, thermal, chemical, fluid, information, sensory, human, software, and transportation interfaces and will include variations based on OFW soldier type, Objective Force mission, and battle space environments.


SLIN 2AU was influenced by the following SLINS: 2AY (NC/CSA); 2AZ (WIN-T/ JTRS), 2CE (FCS Program Review), 2AJ (Baseline Systems Requirements document), and 2AE (Operational Concept).

SLIN 2AY was not influenced by any other SLIN as it was one of the early deliverables in the program. However, it did heavily influence architecture design and operational concept development as Phase I matured.

SLIN 2AZ was influenced only by 2AY (NC/CSA), as it was one of the early deliverables in the program. However, it did heavily influence architecture design and operational concept development as Phase I matured.

3.4.5.1 FCS Interface Implications

Wolfpack has identified a number of OFW-FCS integration opportunities in Phase I. The following tables (Exhibit 10) summarize some of the perceived higher-risk items across Programmatic, Technical, and Operational areas. Some opportunities are listed under two or all three integration areas. This indicates that programmatic, technical, and/or operational approaches pursued in parallel will help resolve the integration issue. An example is the control of robotic platforms. From a technical perspective, all robotic


26

platforms require similar command and control instructions, communications protocols, and software to electronically interface with a single controller. From an operational perspective, the soldiers training, tasks, equipage planning, etc. will involve a single controller to control the various pertinent UGVs or UAVs. From a programmatic perspective, the controller must be developed, scheduled, and funded in coordination with FCS and OFW-run robotic platform programs to ensure proper integration, requirements, and performance and mitigate programmatic risk.

Programmatic Integration Control of Robotic Platforms Soldier control interface (worn or carried), should be able to control multiple types of

platforms (i.e., MULE, Class I/II UAV). Single interfaces (one for each type of robotics) will add unnecessary power and weight.

Common Format for Displays/Information Combat ID Reliance on JTRS for air-to-ground is high risk given maturity of JTRS program.

Unacceptable Power/Weight Considerations for Dismounted Employed Equipment Some FCS delivered/envisioned equipment that will be employed by OFW forces may be

outside the parameters or O&OC developed by OFW. A 2.5-ton Armed Robotic Vehicle (ARV) may be outside weight and mobility characteristics envisioned by OFW.

Need to examine and coordinate on the following: ARV, Small Unmanned Ground Vehicle (SUGV), Organic Aerial Vehicle Light (OAV-L), hand-emplaced sensors/data streams from sensors.

Digital Terrain Elevation Data Level Terrain/Terrain Data FCS requires Digital Terrain Elevation Data (DTED) Level II; OFW requires DTED Level IV

(minimum). Computing, storage, and delivery of the data must be addressed. The issue of rapid digital terrain development from overhead pictures via other platforms

must be developed. Unit of Action Address all soldiers across the UA to include Infantry, Reconnaissance (Recce), Command

Post protection, Combat Support/Combat Service Support (CS/CSS), medics, engineers, etc.

FCS Platforms Address all 19 (current number) platforms.


27

Technical Integration Control of Robotic Platforms Soldier control interface (worn or carried) should be able to control multiple types of


Need FCS Publication/Subscription Layer In OFW Architecture An open interface to the FCS information store must be provided to enable the OFW

information distribution architecture. Address OFW Needs When Away from FCS/UA Systems Need sensor-to-soldier C4ISR data path (i.e., no FCS node).

Common Format for Displays/Information Mission Rehearsal System Must interact to provide a common rehearsal platform.

Sensors Sensor feeds to update Common Operating Picture (COP)/SA from all UA-employed assets

must be available to OFW. Sensor feeds from Unit of Employment (UE) assets may be required to OFW equipped

units under some conditions. Combat ID Must address dismounted-to-dismounted scenarios. Must address ground platform-to-dismounted scenarios. Must address air (fixed & rotary) platform-to-dismounted scenarios.

Must Be High Level of Commonality Between OFW/FCS Spare parts. Consumables (e.g., ammo, power supplies). Major system components (e.g., computers, memory chips, displays).

Need Open Architecture in FCS OFW will be developed with an open architecture allowing technology plug ins and

upgrades in the future. FCS architecture must support the same.

Training Systems Training systems must interact. Training systems for dismounted must be wireless even if FCS is hard-wired.

Combat ID Must address dismounted-to-dismounted scenarios. Must address ground platform-to-dismounted scenarios. Must address air (fixed & rotary) platform-to-dismounted scenarios.

DTED Level Terrain/Terrain Data FCS requires DTED Level II; OFW requires DTED Level IV (minimum). Computing,

storage, and delivery of the data must be addressed. The issue of rapid digital terrain development from overhead pictures via other platforms

must be developed. Ease of Infantry Carrier Vehicle (ICV) platform after battle Connection (physical or electronic) to services (e.g., power, SA, water). Medical assessment and assistance.

Unit of Action Address all soldiers across the UA to include Infantry, Recce, Command Post protection,

CS/CSS, medics, engineers, etc. FCS Platforms Address all 19 (current number) platforms.


28

Technical Integration Operational Integration

Control of Robotic Platforms Soldier control interface (worn or carried) should be able to control multiple types of


Need FCS Publication/Subscription Layer In OFW Architecture FCS is just a plug in to get access to FCS SA/Information. Currently FCS uses client-

server. This approach must to be examined. Address OFW Needs When Away from FCS/UA Systems Current belief/focus that OFW-equipped units will always be with FCS/UA system.

Discounts airborne/long air assault operations. Employment Concept OFW will fight in all four FCS paradigms. OFW will fight away from FCS umbrella. OFW will fight in forced-entry/early-entry scenarios: This scenario (forced entry) has not

been addressed in UA scenarios or O&OC. Squad Compartment Layout/Storage Space Space defined in ICV crew compartment prior to squad/small unit equipment defined by

OFW. External storage should be considered for only non-mission-essential equipment. MULE must be available immediately by dismounted unit. Options should include Towbar,

Ramp-Loaded, Top-Loaded. Training Training systems should be force-wide, not platform-to-platform dependent. DTED Level Terrain/Terrain Data Use of terrain/mapping data is critical to both FCS and OFW.


outside the parameters or O&OC. Developed by OFW. A 2.5-ton ARV may be outside weight and mobility characteristics

envisioned by OFW. Ease of ICV Platform after Battle Vehicle entry. Medical assessment and assistance.

FCS ICV will be Developed Without OFW Requirements Small unit size is being pre-determined at 11. Egress appears cumbersome; no escape hatch.

Too Many Sub-systems will be Integrated Into FCS Platforms OFW soldiers should be able to take away critical FCS sub-systems if needed (especially

if platform is disabled) (e.g., radios, ammo, weapons, power supplies). Unit of Action Address all soldiers across the UA to include Infantry, Recce, Command Post protection,



29

Technical Integration Control of Robotic Platforms Soldier control interface (worn or carried) should be able to control multiple types of


Need FCS Publication/Subscription Layer In OFW Architecture An open interface to the FCS information store must be provided to enable the OFW

information distribution architecture. Address OFW Needs When Away from FCS/UA Systems Need sensor-to-soldier C4ISR data path (i.e., no FCS node).

Common Format for Displays/Information Mission Rehearsal System Must interact to provide a common rehearsal platform.

Sensors Sensor feeds to update Common Operating Picture (COP)/SA from all UA-employed assets

must be available to OFW. Sensor feeds from Unit of Employment (UE) assets may be required to OFW equipped

units under some conditions. Combat ID Must address dismounted-to-dismounted scenarios. Must address ground platform-to-dismounted scenarios. Must address air (fixed & rotary) platform-to-dismounted scenarios.

Must Be High Level of Commonality Between OFW/FCS Spare parts. Consumables (e.g., ammo, power supplies). Major system components (e.g., computers, memory chips, displays).

Need Open Architecture in FCS OFW will be developed with an open architecture allowing technology plug ins and

upgrades in the future. FCS architecture must support the same.

Training Systems Training systems must interact. Training systems for dismounted must be wireless even if FCS is hard-wired.

Combat ID Must address dismounted-to-dismounted scenarios. Must address ground platform-to-dismounted scenarios. Must address air (fixed & rotary) platform-to-dismounted scenarios.

DTED Level Terrain/Terrain Data FCS requires DTED Level II; OFW requires DTED Level IV (minimum). Computing,

storage, and delivery of the data must be addressed. The issue of rapid digital terrain development from overhead pictures via other platforms

must be developed. Ease of Infantry Carrier Vehicle (ICV) platform after battle Connection (physical or electronic) to services (e.g., power, SA, water). Medical assessment and assistance.

Unit of Action Address all soldiers across the UA to include Infantry, Recce, Command Post protection,



30

Operational Integration Control of Robotic Platforms Soldier control interface (worn or carried) should be able to control multiple types of


Need FCS Publication/Subscription Layer In OFW Architecture FCS is just a plug in to get access to FCS SA/Information. Currently FCS uses client-

server. This approach must to be examined. Address OFW Needs When Away from FCS/UA Systems Current belief/focus that OFW-equipped units will always be with FCS/UA system.

Discounts airborne/long air assault operations. Employment Concept OFW will fight in all four FCS paradigms. OFW will fight away from FCS umbrella. OFW will fight in forced-entry/early-entry scenarios: This scenario (forced entry) has not

been addressed in UA scenarios or O&OC. Squad Compartment Layout/Storage Space Space defined in ICV crew compartment prior to squad/small unit equipment defined by

OFW. External storage should be considered for only non-mission-essential equipment. MULE must be available immediately by dismounted unit. Options should include Towbar,

Ramp-Loaded, Top-Loaded. Training Training systems should be force-wide, not platform-to-platform dependent. DTED Level Terrain/Terrain Data Use of terrain/mapping data is critical to both FCS and OFW.


outside the parameters or O&OC. Developed by OFW. A 2.5-ton ARV may be outside weight and mobility characteristics

envisioned by OFW. Ease of ICV Platform after Battle Vehicle entry. Medical assessment and assistance.

FCS ICV will be Developed Without OFW Requirements Small unit size is being pre-determined at 11. Egress appears cumbersome; no escape hatch.

Too Many Sub-systems will be Integrated Into FCS Platforms OFW soldiers should be able to take away critical FCS sub-systems if needed (especially

if platform is disabled) (e.g., radios, ammo, weapons, power supplies). Unit of Action Address all soldiers across the UA to include Infantry, Recce, Command Post protection,


Exhibit 10. Programmatic, Technical, and Operational OFW-FCS Integration Risks


31

3.5 Life Cycle Analysis

3.5.1 Link to Program and Process Management Process

Exhibit 11. Life Cycle Analysis Link to Program Management

3.5.2 2BK-2BK1 Executive Summary

3.5.2.1 Life Cycle Cost Containment Strategy

The fundamental focus of the Life Cycle Cost (LCC) Containment Strategy is the identification, management, and reduction of costs throughout the life of the OFW program as part of an iterative development process. As a result of the uniqueness and


32

scope of the OFW program, encompassing improvements to the entire DOTMLPF framework, we realize that many areas of cost will ultimately be addressed through the Wolfpack approach. Our approach is comprehensive, encompassing the OFW program in its entirety (S&T, System Development and Design, Production and Operations and Sustainment), and flexible to address cost containment in the Evolutionary Acquisition (EA) paradigm. The very nature of the Wolfpacks EA approach requires concurrence of design and cost team activities to ensure that the full breadth of program costs are considered throughout all phases of the program and at all junctions in system development.

The cost team activities performed in Phase I, to include the establishment of the Land Warrior baseline, involvement in the technology assessment and selection process, and the establishment/understanding of a preliminary Block I concept that allowed for the Land Warrior/OFW baseline comparison, provided a basis for the identification of a preliminary set of cost drivers anticipated for OFW and establishment of an initial LCC model framework.

The true value in cost containment begins to take effect in Phase II. Wolfpacks cost containment efforts in this phase will support the extensive M&S, testing, and Analysis and Assessment (A&A) activities that will play a crucial role in Phase II. Phase II will involve a more rigorous evaluation of the selected technologies and their alternatives with respect to cost, performance, and schedule. During Phase II, the Wolfpack Cost Team will participate in the Wolfpack Design Team activities regarding hardware selection by building on the information resulting from Phase I activities and introducing empirical analysis elements into the system design process. Additionally, the cost team will consider the cost impact of considering immature technologies for future blocks through Real Options Analysis.

Phase II will involve the continued analysis, data collection, and development of an LCC model and estimate that encompasses the entire program life cycle, as well as reflects the associated cost impacts across the operational (DOTMLPF) spectrum, to include those originating in key system relationships (i.e., FCS) and interfaces. The establishment of an initial OFW LCC model will yield a quantitatively based set of OFW cost drivers and define the OFW cost baseline. Early establishment of a cost baseline will allow the cost team to perform program cost sensitivity analysis (i.e., what if drills) associated with programmatic decisions throughout Phases II and III. Moreover, identification of OFW cost drivers early in Phase II will form the basis for developing an initial Cost as an Independent Variable (CAIV) plan that will be refined through Phases II and III. The OFW program will employ techniques such as contract incentives to manufacturers in order to reduce program LCCs. Cost strategies will vary depending on the item being supplied, whether it is a Commercial Off-The-Shelf (COTS), Government Off-The-Shelf (GOTS), or unique design part. Establishing the CAIV plan early in Phase II will assist in containing and reducing costs where possible through the use of vendor alliances, contract incentives, and cost incentives.


33

In Phase III, limited production and testing, the Wolfpack Cost Team will continue to use a myriad of tools such as CAIV analysis and will continue to update the Life Cycle Cost Estimate (LCCE) to reflect the program baseline. Any changes made in Phase III will be quantitatively assessed using the LCCE and included in the CAIV plan. A CAIV plan begins to take shape in Phase II and is continually refined throughout the Phase as system design is solidified. By Phase III, the cost team will have established a definitive CAIV plan and will continue to work with vendors to achieve the goals identified in the plan.

3.5.3 2BC-2BD Executive Summary

3.5.3.1 Life Cycle Capability Upgrade Strategy

The objective of the Wolfpacks Life Cycle Capability Upgrade Strategy (LCCUS) is to define the means through which we will develop, produce, deploy, and sustain an initial Core capability (Block I) and then present the plans for subsequent development, production, fielding, and sustainment of increments beyond this initial capability over time. This strategy provides for the ability to adapt to a changing environment by allowing for the accelerated acquisition and fielding of a militarily useful core capability and allowing for proactive, recurring improvements to be made to the system over time.

The over-arching acquisition approach that Wolfpack has adopted, from the outset, with regards to OFW is an EA strategy. An EA strategy is an approach to systems acquisition that defines, develops, produces/acquires, fields, and sustains an initial increment (block) of operational capability based on available technologies demonstrated within a relevant environment, and then presents the plans for subsequent development increments beyond this initial capability over time. The goal of each increment is the delivery of a militarily useful (i.e., an acceptable level of military utility such that, absent future funding, the fielded system is sustainable and of use and value to the warfighter) capability and represents a predefined percentage of the systems final desired capability. Within the construct of the LCCUS, a Technology Insertion (TI) plan will serve as the means by which the system and its associated operational capability can be maintained and sustained, kept up to date avoiding sustainment problems and obsolescence, and receive advantages that come from newer technology.


3.5.4.1 Life Cycle Cost Containment Strategy

The concept development activities conducted in Phase I provided the foundation for the OFW program and represented the first steps toward defining the OFW baseline. In addition, Phase I established the means by which system obsolescence through TI will be addressed. In essence, Phase I amounted to exploratory activities within the art of the possible and focused on the identification of a performance-driven Block I core solution that included cost as a discriminator, and the operational framework within which current and future Block concepts will operate.


34

During Phase I, the cost team participated in design activities/processes, ensuring that cost implications associated with technology selection/investment were understood and, thus, could influence technology identification and system design. By bringing the cost team in at such an early stage, Wolfpack can identify and mitigate a large amount of the cost risks associated with the OFW project before they ever become a serious issue. Cost containment activities began as early as the requirements identification process, thereby establishing the means by which system costs are contained throughout the system life cycle. The cost team made sure that costs that are not usually realized until the system is fielded (e.g., operations and maintenance) and that comprise the larger share of Total Operating Cost (TOC) are considered and measures are taken to minimize the cost impact early in the process by including key parameters such as readiness levels and operation and maintenance cost implications in the requirements identification process.

3.5.4.2 Life Cycle Capability Upgrade Strategy

Wolfpacks LCCUS is designed to provide for seamless TI, identification and replacement of obsolete parts, and identification of promising technology and planning for its incorporation. The OFW architecture is intended, by design, to foster flexibility, modularity, and freedom in design choices through the use of standards and evolutionary development for all of the elements that comprise this SoS. Achieving this freedom and flexibility without sacrificing system effectiveness or incurring unacceptable cost and delay requires a strong and reliable open architecture. Our modular open systems design will be amenable to absorbing new technology and will provide the flexibility for future growth. The architecture will play an evolving role through the OFW life cycle and will remain an essential element of the rapid spiral evolution of system concepts.

The definition and characterization of major system interfaces is a necessary part of the development of the OFW Technical Architecture. The definition of the fundamental functional partition of OFW, the assignment of functions within that partition, and the rules within which system elements interact enable efficient and nearly independent design of each element within the system with minimal penalties on system performance. Interfaces and interactions in an open architecture environment are controlled by standards and parameters that help define the tolerances that govern system design and technology selection. In meeting this goal, Wolfpack has adopted a standards-based approach to engineering the OFW system. Wolfpacks goal is to create an architecture that is controlled by standards, yet is non-constraining to allow for seamless integration of future increments. The standards control the interfaces without constraining interaction or system design by broadly defining the thresholds for each interface. Broad standards are chosen to ensure interoperability and reliability of system configuration and management as technologies are chosen. Standards that would mandate specific technology choices are avoided where possible.

The OFW concept is based on an SoS architecture, designed to interface effectively with Legacy, Interim, FCS, and Objective Force systems. As the systems evolve through future increments, maintaining interoperability and reliability of system design is


35

achieved through the selection of standards and control parameters. Applicable and widely accepted commercial, international, governmental, and military standards are identified as means to control system partitions and interfaces. Standards chosen to guide future system design modifications will be consistent with the Joint Technical Architecture - Army (JTA-A) and other legacy systems in order to facilitate interoperability.

The key to the success of this strategy hinges on following a disciplined and structured set of processes. The Wolfpack SE process provides the structure that permits efficient coordination of many complex activities and the discipline that minimizes risk by ensuring that necessary factors are considered and the team remains cognizant of vital information. At the center of the processes is an information system that tracks the status of evolving technologies, the life and status of fielded equipment and systems, new capability needs, and materials and parts being phased out of production or support. Technology searches feed a database documenting the screening of technologies for readily apparent, major shortcomings in the their ability to address relevant operational capabilit