From now to the Objective Force: an architectural approach to Soldier Systems - Soldier Systems - Brief Article

COL. THEODORE "TED" JOHNSON

How do you integrate, produce, and support systems that use rapidly changing technology, but also evolve to meet the soldier's needs for today, tomorrow, and for the next two decades? As the acquisition manager and integrator for all items worn or carried by the soldier, U.S. Army Project Manager Soldier Systems, known as PM Soldier Systems, is facing this difficult question.

Soldier Systems Architecture

PM Soldier Systems employs a "System of Systems" approach combined with an expandable architecture. This provides plug-and-play functionality for sensors, weapons, electronics, and soldier equipment. Our current activities center on developing a Soldier Systems Architecture "Framework" that defines external interface relationships, establishes system modularity, and specifies interfaces among individual modules that are integrated into the systems to satisfy soldiers' needs.

We use metrics that assess successful integration of components into a weapons platform centered on the soldier. Weight carried by the soldier is one of these metrics. As shown in Figure 1 (p. 100), many components were developed over the years, each optimized to provide essential functions to the soldier on the battlefield. But total weight carried by the soldier was a by-product, not a metric.

The result is that the soldier's combat load, depending on specific missions, has grown to more than 92 pounds.

Our long-term goal is to integrate the soldier's ensemble and mission components, incorporating the products of science and technology efforts, along with developments in the commercial sector. The fully integrated warrior system increases infantry soldier capabilities and meets program metrics for weight, space, balance, power, and reliability at a reasonable cost.

Soldier Systems evolution depends on future technology such as faster low-power computer chips, improved materials, and new ballistic protection. By close coordination with the research and development community, market analysis of commercial technologies, and focused emphasis on communicating key requirements, we plan to leverage change as it occurs.

Relying on cutting-edge technology generally places the responsibility for module design, development, and conformance testing in the hands of industry. The supporting acquisition strategy employs performance requirements and thorough testing to select updated modules for the evolving systems.

More on Architectures

Since 1998, PM Soldier Systems has moved aggressively to implement Open Systems into the initial Soldier Systems Architecture. We know that the architecture framework changes more slowly than the design solutions and technology of individual modules. Open Systems use widely available and consensus-based interface standards as part of the system framework. Advantages are that a wide selection of market-based components are available, plus economy of scale and commercial sector technology advances can directly address sustainment and obsolescence. Existing government items and legacy components use adapters to interface with the architecture, when needed.

Significant thought and effort went into the conceptual design and decisions associated with the architecture. We examined a variety of alternatives for meeting interface performance levels and conducted analysis to forecast the longevity of open interfaces. The result is a system architecture that is best viewed as a multi-dimensional figure, of which a portion is depicted on the next page (Figure 2).

The Soldier Systems Architecture includes user needs--the functional architecture--on the front face of each cube. The physical architecture--system modularity--can be related to each element of the functional architecture and is shown on the top of each cube depicted in Figure 2.

Corresponding technical architecture interfaces, shown on the right side of the cube, apply to every module. The horizontal plane forms the physical architecture, while the other two planes define the functional and technical architectures. The total three-dimensional representation is a Soldier Systems Architecture that meets user requirements, incorporates modularity, and uses Open Systems interfaces.

Functional Architecture

User needs are the starting point for developing the Soldier Systems Architecture. Currently, the needs of the infantry soldier addressed by the Land Warrior system (shown in Figure 3, p. 101) are leading a set of similar "platforms." Users are developing or identifying requirements in other combat "domains," including armor, aircraft, special operations, medic, combat engineer, and artillery. Support-type requirements are also being refined for platforms in areas such as maintenance and logistics.

The Soldier Systems functional architecture identifies a set of requirements that, when grouped, provides significant benefits to the acquisition process. Managing a set of functions and the modular solutions for those requirements allows us to minimize stovepiped development efforts for multiple systems, reduces procurement cycle time through module reuse, and allows common sustainment concepts.

Identifying Common Functions Across Multiple Platforms

Organizing the functional architecture considers the degree of commonality across different warrior platforms. This effort will produce significant payoffs in terms of dollars, time, and life cycle support. Further, it can be expected to streamline activities such as safety and security certifications. Many of these functions apply to several warrior platforms illustrated in Figure 4, p. 1-1.

As shown in Figure 4, core functions are part of all warrior platforms. While common functions apply to many of the platforms, a set of unique functions applies only to individual platforms. By concentrating first on satisfying the core functions, we can obtain the maximum benefits.

The functional architecture and degree of commonality help us identify areas first in line for the next step--establishing elements in the physical architecture. Some of these core functions are communications, information handling, sustainability, user interface, environmental protection (uniforms), electrical power, and training.

Establishing Modularity for the Physical Architecture

The next step involves developing a physical architecture of hardware and software elements. Following that, we select the interfaces for these modules. Logistics concepts, use of existing government or commercial items, and potential for reuse all affect module-partitioning decisions.

Establishing the level of modularity is one of the most difficult parts of the Soldier Systems Architecture development process. A highly integrated multi-purpose and multifunction package is an attractive solution. This alternative increases system complexity, but tends to reduce production costs. It will create a supportability nightmare when internal parts fail.

On the other hand, a highly modular solution increases weight and requires additional connectors, cables, and other interfaces. This will increase production costs, may reduce sustainment costs, and can create an integration challenge.

The degree of modularity and number of interfaces must be considered in terms of our system metrics of power, weight, space, and reliability. The challenge is to achieve a happy medium with functions distributed across a manageable set of modules. This is where the functional architecture can help. By orienting partitioning with the core functions in mind, we obtain modules that directly relate to all platforms. These modules have a high potential for reuse. Other modules can be grouped to support common functions, producing modules that have good reuse potential.

When core and common functions aid module partitioning, economy of scale will give us a set of reasonable cost components within the constraints of the sustainment concept. The number of interconnects must not adversely impact weight, bulk, and reliability Software modularity, which is part of this decision process as well, directly affects the complexity of future modifications and the software portability to multiple platforms.

The Work Breakdown Structure (WBS) captures our physical architecture decisions. It defines the subsystem modules and major components that relate to user requirements in the functional architecture. The following list includes WBS items typical of those that contribute toward core Soldier Systems functions:

* Uniforms, Clothing, and Individual Equipment

* Data Processing

* Voice and Data Communications

* Position Determination and Navigation

* Power

* Software Operating System

* Software Application Modules

* Input, Output, and Controls.

After developing the physical architecture, the next step is selecting interfaces for the system modules. The technical architecture defines these relationships.

Technical Architecture

The official definition for technical architecture is spelled out in DoD Joint Technical Architecture 3.1, dated March 31, 2001, which states that a technical architecture is:

"... A collection of the technical standards, conventions, rules, and criteria organized into profile(s) that govern system services, interfaces, and relationships for particular systems-architecture views and that relate to particular operational views."

The technical architecture provides a means to achieve interoperability among different platforms and systems. DoD created the Joint Technical Architecture (JTA) to define a minimum set of interface standards and development guidelines for acquisition programs. The Army developed the JTA-Army (JTA-A), to assure interoperability for Joint and Army programs that electronically produce, use, or exchange information.

The Soldier Systems Technical Architecture defines interfaces, both external and internal, that connect the system, subsystem modules, and in some cases, the internal components. These interfaces are part of the system requirements and also constrain the design efforts by pre-selecting module interfaces.

The interoperability-related guidance in the JTA and JTA-A are only a part of the Soldier Systems Technical Architecture. The JTA provides choices for Human-to-Computer, Data Transfer, Information Processing, and Information Security activities. Categories of mandatory and optional emerging standards include military and open systems interfaces associated with exchanging information.

The Soldier Systems Architecture takes these into account, but goes beyond information exchange. We are concerned with issues typical of the following:

* What is the physical mounting for modules on the soldier's load carrying equipment?

* How do we mount sensors on government-supplied weapons?

* What should our user interface control look like?

* Can we use common connectors, and what should they be?

* If the soldier interacts with a menu screen, can it be standardized?

* How can we adapt to legacy components, modules, and external systems?

Interface Selections

Physical architecture partitioning must be underway before selecting interfaces for the technical architecture. We define appropriate interfaces to the level of the lowest WBS element. Further, lower-level internal interfaces are part of the design process and are not captured in the technical architecture. For our interface selection, we use available open systems interfaces, where appropriate. In other cases, we use JTA-mandated standards. Some interfaces may be military-specific, especially where legacy components are system modules. The goal is to establish a set of interface standards that meets a broad performance range to permit future growth, while applying a single technical architecture to multiple platforms. The following interface standards are examples of those used in the Soldier Systems Technical Architecture:

Physical

Weapon Mounts--MIL STD 1913 (Picatinny Rail)

Logical

Transmitted Messages--Joint Variable Message Compatibility

Data Interface--Universal Serial Bus VI.1

Legacy--Ethernet 10/100 Base T, RS170, RS-232/422

Electrical

Power--DCV 8-28 input, 110/220VAC 50/60 Hz (with adapter)

Human Factors

Map Symbols--MIL STD 2525B Common Warfighting Symbology (augmented)

Soldier Systems Supplement to Army Human Computer Interface Style Guide.

Architecture Coordination

The Soldier Systems Architecture--composed of functional, physical, and technical elements--is being used for warrior platforms now in development. The technical architecture interfaces represent our best estimates for long-lived standards that form the framework for all warrior platforms. These interfaces are key to the plug-and-play system evolution strategy.

Other Army and government programs develop equipment that is part of the modular physical architecture. One additional aspect of managing the architecture is coordination with these external agencies and suppliers.

For example, PM Night Vision continually develops new sensors with potential application across warrior platforms. If we intend to incorporate new night vision sensors, the plug-and-play concept only works when the producer uses interfaces consistent with our technical architecture. Other requirements, such as the need to remove self-contained batteries and plug into warrior platform central power, are design issues. We cannot operate in a vacuum, but must be proactive, working with warrior platform users, government development agencies, and commercial suppliers.

Figure 5 lists some of the many agencies involved in this process. PM Soldier Systems is now coordinating the technical architecture. When the work is complete, we plan to update the Soldier Systems Annex in the JTA-Army.

The Evolving Soldier Systems Architecture

Our Soldier Systems Architecture can be fully coordinated and documented, but it will never be finished. We recognize that change will always be a factor. The functional architecture evolves with each newly identified user requirement or new warrior platform. This drives reevaluation of the physical architecture. Physical architecture changes, along with advances in technology and marketplace developments, will cause us to re-examine the technical architecture as time goes by.

With this in mind, we can now answer the question posed at the beginning of this article. We expect that the system interfaces will have much longer life spans than the materials, processes, and designs of system modules. However, there will come a point when we must migrate to new technical architecture interfaces for Soldier Systems platforms that support the Army's Interim Brigade Combat Team, and ultimately, Objective Force Warrior. This should not be wholesale change, but an evolutionary process. The functional, physical, and technical elements of the Soldier Systems Architecture--combined with users' key performance parameters and our metrics of weight, power space, balance, reliability, and cost--will guide the process.

Editor's Note: The authors welcome questions or comments on this article. Contact Johnson at tjohnson@pmsoldier.belvoir.army.mil; Gillis at mgillis@ pmsoldier.belvoir.army.mil. More information on technical architectures is available on the Web at http://www.jta.itsi.disa.mil/.

Johnson is the Program Manager, Soldier Systems, Ft. Belvoir, Va. Gillis is with BRTRC Technology Research Corporation providing system-engineering support to PM Soldier Systems.

COPYRIGHT 2002 Defense Acquisition University Press
COPYRIGHT 2003 Gale Group