Recapitalization of tactical computer-automation systems

by LTC Jerome Payne

"The Department of Defense continues to face a limited investment budget constrained by a relatively stable top-line budget, and squeezed by increased operations and support cost for aging weapons systems.� � Jacques Gansler, �Recapitalization: a key element of Army transformation,� Army AL&T Magazine, January-February 2001.

The current pace of commercial-off-the-shelf computer-component migration is adversely affecting the projected useful life of the Army�s new ruggedized tactical computer systems � accelerating planned rebuy/refresh funding points for product/program managers and making it difficult to accurately develop cost-effective recapitalization strategies for their fielded systems.

The purpose of my article is twofold. First, it�s to analyze and discuss the Army�s implementation of Secretary of Defense William Perry�s 1994 directive to integrate and leverage COTS components in the design and production of systems the Defense Department develops and procures. In this part of my discussion, I intend to highlight the advantages and disadvantages of COTS components as they�re integrated into today�s tactical computers and automation hardware systems.

The second purpose is to identify a number of recommendations (some obvious, some not so obvious) as to what can and should be done to recapitalize and get the most out of our materiel investment. Whether referring to the activity as modernizing, recapitalizing, rebuilding, rebuying or refurbishing, the real question on the table from the Army leadership is, �What can be and is being done to extend the useful life of our $1 billion-plus investment in tactical automated systems supporting digitization and ultimately the Army�s transformation program?�

Since the end of Operation Desert Storm, the Army and other DoD agencies have procured more than 10,000 computers, most of which are ruggedized and designed for use in several types of harsh environment. This number only reflects tactical computers built and delivered by way of the Army�s Common Hardware Systems program; it doesn�t reflect computers that may have been procured through a myriad of other contract vehicles. So the total number of tactical computers in operation today may well be in numbers of an even greater magnitude.

The important point here is to demonstrate the immense proliferation of tactical automation systems the Army and its �sister� services use since that proliferation began in the late 1980s and early 1990s, as well as to outline the need for a plan addressing recapitalization of this significant investment.

Background

As I mentioned, in 1994 Perry implemented an initiative that essentially moved the services toward a COTS approach to materiel development. DoD promoted this initiative, an aspect of the Acquisition Reform Act, to contain military costs by eliminating the design of customized application-specific systems.

The initiative forced the services to reduce their traditional reliance on military specifications for materiel acquisition and to seek out COTS solutions whenever and wherever applicable. Commercial standards and specifications became the norm; in the years that followed the 1994 initiative, the services had to request special waivers on mil-spec to procure items. The impetus for this initiative was clear. It was in DoD�s best interest to leverage research, development and acquisition investments in the commercial sector, and in so doing, free up declining defense dollars for other pressing requirements such as combat system modernization, training and procurement.

Since the Cold War�s end, U.S. defense spending has dropped 40 percent of what it was at its peak, and DoD�s procurement budget is down by 65 percent, according to Phillip Hamilton�s article, �Military Electronics and Obsolescence,� COTS Journal, March 2001. Military influence in the electronics and semiconductor market has reduced proportionately. In the 1970s, the military purchased and controlled more than 30 percent of the electronics sector. By the mid-1980s, the military�s share had fallen to about 7 percent. Today DoD purchases less than 1 percent of the industry�s total semiconductor output, according to Hamilton.

When the military lost its market share, it lost its influence. The bottom line is that today COTS development is driven by consumer need and commercial trends, and DoD is primarily a spectator, forced to leverage commercial-technology developments rather than direct them.

What does that mean to the Army? On one hand, military system developers love the low-cost, cutting-edge technology COTS materiel integration provides; however, COTS� major downside is the short obsolescence cycle and lack of corporate incentive to ensure the next-generation component seamlessly integrates into the old system. Technical experience in this area is that seldom, if ever, does the next-generation component fit into the previous system, share the same footprint or work easily with earlier external system interfaces. Components that do usually require significant program funding to rehost system software, develop new drivers, update firmware or customize circuitry to accommodate next-generation voltage architectures � for example, the five-volt transition to 3.3 volts or 1.8 volts.

In view of these challenges, how will the Army maintain a system for 10 to 15 years when the integrated commercial electronics will be obsolete in 18-24 months and, for the most part, no longer available?

Digitization and Army transformation

To understand the overall complexity of the COTS issue as it relates to fielding schedules and the Army�s unit-set-fielding initiative, it�s important to understand where we were as an Army and where we�re going with transformation. With the Cold War�s end, the Army was forced to take a good look at itself and its relevancy regarding the type of operations it would be called on to respond to in the future.

It was clear that as the force reduced in size, joint operations would become far more important. Operations-other-than-war would become the norm; warfare would no longer be fought on a linear battlefield. Network-centric warfare would be the future. Success would hinge on the ability to see and influence the battlefield three dimensionally and at greater distances with fewer forces than ever before.

Seamless integration of command, control, communications, computers and intelligence systems is critical to this new method of warfare. So the Army�s challenge is to change an acquisition process that at one time supported many �stovepipe� information systems and meld it into a functional, interoperational communications architecture. What followed the mid-1990s adjustment to COTS was a series of advanced warfighting experiments intended to identify �high-payoff� technologies and shake out network C4I shortcomings.

From the warfighters� perspective, their mission was clear: learn how to use and employ the new information-technology systems to increase the unit�s lethality and protect our forces. But for the PMs on the materiel-acquisition side, acquisition transformation introduced a whole new set of challenges, many of which they continue to wrestle with today.

First, their programs all have different acquisition strategies and fielding schedules. Second, each program is funded separately, independent of the maturity level of C4I programs with which it may interoperate. Third, each program is controlled by a different Training and Doctrine Command training center established to meet different requirements as laid out in the approved operational-requirements document. To further exacerbate the situation, many of the system ORDs have different environmental-performance requirements, in spite of the fact that these systems will, in most cases, have to perform side-by-side in the same environment.

What exactly is COTS?

COTS IT refers to a range of available hardware and software industry produces for use in commercial markets. It may refer to board-level components built into a product or system, or it may refer to a complete end-product or system. Since COTS is produced by the commercial sector, its development and marketing reflect typical commercial priorities such as cost competitiveness, time to market and the ability to capture market share (percent of the commercial market the firm wants to own and control), according to Dr. Alex Weiss in his September 2000 thesis on using COTS IT in operational defense equipment (Defense Engineering Group, University College of London).

When the Army decided to use COTS in a tactical environment, no one knew just what the implications of COTS integration might be. Even the term COTS means different things to different customers. If you ask anyone in the commercial sector to define COTS, their answer will be something you can buy and use �as is� directly from the vendor. DoD has a somewhat different definition, however. To DoD, COTS means that an item is manufactured using best commercial practices. The spirit of COTS is to use products, technologies and services that are readily available from industry without a government or military contractor having to develop them from scratch, according to Danny Oscadca, �Future of harsh environment and mission-critical COTS,� COTS Journal, May 2001.

The problem is there are few, if any, commercial contractors who manufacture computer or automation products that are sold on the consumer market and can meet Army user requirements �off the shelf� or �out of the box� as defined in an approved ORDs without, in some cases, significant modification. Further, the operational-test community has shown tremendous reluctance in granting any program relief or negotiating a compromise in key-performance parameters as stated in the user�s ORD, in spite of how unrealistic some KPPs may be when evaluated in terms of the technical maturity of similar systems in the commercial market. Often this dilemma results in a good program dying a slow but certain death because the old paradigm of tailoring specific military development efforts and high user expectations can�t be met with a pure COTS solution. If they could, the cost to modify or adapt COTS technology may prove to be cost-prohibitive.

In the end, the materiel developer could have provided the user leap-ahead capability and, by integrating COTS, could have kept the cost within available program-funding parameters. Instead, the user loses out because COTS �as is� cannot meet the KPP, and developing an objective system which meets all the user�s requirements is cost-prohibitive.

Using COTS requires a number of trade-offs based upon the environment in which it�ll be used. Army Materiel Command, Communications-Electronics Command and subordinate program executive offices are aggressively implementing Perry�s vision of COTS integration using a strategy called �adopt, adapt and develop,� as discussed by James Barbarello and Walter Kasian in a March 2000 white paper titled �U.S. Army COTS experience: the promises and realities.� Each approach is explored based on the specific requirement, implementation cost and development schedule of the product.

The strategy of adopting COTS is certainly the most preferred from both a cost and schedule perspective; however, most systems required to operate in a field environment must, as I said earlier, undergo some degree of modification or adaptation to meet functionality and reliability requirements. Therefore most computer hardware procured and provided to combat units to date has been adapted COTS � components are modified or ruggedized to meet clearly defined performance parameters and packaged to meet a specific integration footprint.

The term adapted refers to the fact that at the board level, components in these tactical computers are pure COTS. However, to increase system reliability, robustness and tolerance to a full spectrum of environmental stresses, a number of manufacturing modifications must take place that may include (but would not be limited to):

  • Exterior casings may be specially designed to absorb impact shock if the item is dropped;
  • Specially designed removable hard-disk drive encasements are developed to reduce the impact of vibration while the system is in use and the combat platform is on the move (a requirement placed in many system ORDs and the Army Battle Command System�s capstone-requirements document);
  • Electromagnetic-interference gaskets and filtering are integrated throughout the complete system;
  • Printed circuit boards are stiffened (reinforced); and
  • Special mounting arrangements are developed to protect high-risk circuitry.
  • Without these modifications few, if any, commercial-grade computers would survive the demands placed on them in a fully tactical environment. Commercial computers aren�t designed to meet EMI requirements. This is critical in avoiding cosite interference problems created by placing an automation system near or adjacent to other operational data-transmission devices (such as Single-Channel Ground and Airborne Radio System radios).

    Commercial computers and automation systems are also not designed to survive high-altitude electromagnetic pulsing. This is an enemy�s electronic countermeasure designed to destroy operational data systems such as the tactical computer, using a directed high-energy pulse emitted from aircraft or missiles flying over the designated target area.

    The point is that COTS implementation shouldn�t be strictly interpreted to have the military user believe these systems can meet the demands of combat and network-centric warfare with computers purchased directly from the civilian commercial market without being granted dramatic relief from system performance and reliability requirements as established by the user community.

    When Perry announced his COTS and acquisition reform initiatives in 1994, commercial technology was turning over every five to seven years. Today that rate of turnover is occurring about every 18 months.  New microprocessors are entering the commercial market every six months, and next-generation memory families every six to nine months, according to John McHale in �Obsolescence: every COTS designer�s bad dream,� Military and Aerospace Electronics Journal, February 2000 edition.

    Given this scenario, the maintenance cost can be staggering when you consider the current defense budget is forcing the services to get longer and longer service life from their systems. PMs are responsible for ensuring they have adequate funds fenced in the program-objective memorandum to support their out-year recapitalization strategies. It�s necessary to understand that the strategies may vary from PM to PM based on a number of factors.

    Recapitalization: upgrade vs. rebuild vs. rebuy?

    The Army�s recapitalization program clearly defines and delineates a number of possible approaches toward keeping fielded systems refreshed, relevant and formidable.

    Modernization � The development and/or procurement of new systems with improved warfighting capabilities.

    Recapitalization � The rebuilding and selected upgrade of currently fielded systems to ensure operational readiness and a zero-time/zero-mile system. Rebuilding restores a system to like-new condition and inserts new technology to improve reliability and maintainability. Upgrading rebuilds a system and adds warfighting-capability improvements to address capability shortcomings.

    Maintenance � Repair or replacement of end-items, parts, assemblies and subassemblies that wear or break, according to Eric Orsini and COL Glenn Harrold, �Recapitalization: a key element of Army transformation,� Army AL&T Magazine, January-February 2001.

    A successful recapitalization plan for Army automation and C4I systems must implement more than one of the approaches I�ve cited � and, in some cases, must implement them simultaneously.

    In view of the Army�s inability to control the rapid evolution of computer components in the commercial sector, PMs and TRADOC system managers will have to adopt a number of strategies to extend the useful life of their systems. This strategy will require influencing hardware development, as well as closely overseeing software and its tendency to grow exponentially with each subsequent version or release package.

    With regard to software oversight, the Army�s Directorate of Information Systems for C4 � working closely with the deputy chief of staff for operations � has already taken a major step in addressing this potential problem by developing a software blocking policy. The significance of this initiative cannot be overstated. This policy provides executive-level oversight and approval authority for migration of ABCS and all its related applications� software-release packages.

    Any new release package, operating system or improvement to ABCS and its subcomponents must be thoroughly tested at the Central Technical Support Facility located at Fort Hood, Texas, for impact on the system and the network as well as ensuring its stability before it�s released to digitized units. Further, release of subsequent software-release packages will be limited to 18- and 36-month fielding cycles, providing greater stability within the ABCS architecture, reducing operational impact and providing units greater time to train on the new software before implementing the transition.

    Recommendations

    Establish a stable software baseline. The recapitalization activity of tactical computer and automation systems will be varied, based on a number of factors. In May 2001, PM-CHS commissioned a study to evaluate the most probable weak link in our current fielded tactical-computer systems. The analysis � reported in a Unixpros Inc. software-metrics test report for ABCS 6.2 foundation products done at Fort Monmouth, N.J. � showed the processors (at that time 440 megahertz) were in most cases almost fully used at certain times of operation. The computer�s one gigabyte of random-access memory was found to be more than adequate to support combat operations with its current software.

    That being the case, units that have already received or will receive the already-purchased 440-mhz systems should represent the baseline for software development. Future software releases must be evaluated against this hardware baseline until there�s adequate funding to initiate a modernization effort based on a system rebuy for the first generation of fielded systems, since these tactical computers can�t be upgraded beyond the 440-mhz processors installed on their motherboards. (Migration beyond the 440-mhz-processor architecture requires a different commercial motherboard.)

    Conduct trade-off analyses. For systems yet to be fielded to the rest of the First Digitized Corps, PMs will have tremendous latitude for decisions on how and when to recapitalize fielded systems. Based on information from both General Dynamics Communication Systems and Sun Microsystems, the next generation of computer motherboards will be able to support two 650-700 mhz processors and up to two GB RAM memory. The next generation will also be able to house a 73 GB removable hard drive � providing ample room for growth to support future requirements. The greater capacity will mean that cost trade-off analysis will be crucial in determining the cost-effectiveness of procuring a next-generation system vs. cannibalizing legacy systems and incorporating, where appropriate, the older components into the new computer housing and motherboard. As might be expected, this next-generation board doesn�t fit into the exterior housing of the tactical computers currently fielded.

    Increase funding of ABCS system engineering and integration efforts. Although application software (for example, Maneuver Control System and All-Source Analysis System) is being developed to meet individual TRADOC schoolhouse/combat-developer requirements for their respective user, the real strength of digitization comes from the synergy created by the seamless integration and interoperability of ABCS subsystems at the Army level. A solid integration process is key to the success of making ABCS and Force XXI Battle Command Brigade and Below into seamless entities. The only way to ensure this happens successfully is through a solid SE&I effort.

    Control software growth. Computer hardware and software must be seen as �Siamese twins� in that what affects one will surely affect the other. This can�t be emphasized enough! Never lose sight of the fact that the C4I architecture is only as fast and stable as its weakest link. All software, present and future, will have to run as efficiently on legacy systems sent to the field in the last three-five years as it does on next-generation systems going out the door today.

    One of the greatest frustrations for those who develop military-oriented computer hardware today is that PMs simply don�t know what the minimum hardware requirements are to run the current version of ABCS 6.x (or 7 and beyond). Compound this by adding the Solaris 7.0 operating system (with plans to migrate to possible 8.0 or 9.0 in the next year or so), then add the battlefield-functional-area application software. Unlike the �minimum system requirements� printed on the side of a Windows 98 or 2000 box, the Army has yet to determine what the minimum requirements are for using tactical computers and the myriad of software bundles that form that situation-awareness product we refer to as ABCS.

    As the Army and sister services determine software requirements for this new network-centric architecture, it�s imperative CTSF establish �metrics� for determining the minimum and optimum hardware-performance requirements to efficiently run ABCS and all additional software. This will allow PMs to know the requirements of hardware that soldiers of the future need today and to be able to procure these systems with adequate growth built in, but at the same time not pay for performance far in excess of what will realistically be needed.

    Reduce hardware-software interdependencies. System-application software developers often write their software code with a direct dependency on the specific system on which it�s being run (for example, Sun UltraSparc IIi). This should be avoided. Open-architecture should be the standard! There maybe a good rationale for this, but it creates a number of problems for PMs.

    First, any change in hardware platforms or subcomponents such as a hard drive (which is inevitable) requires the contractor to modify, change, tweak or develop the software to make the system continue to run properly. Not only does this take time, but it also leads to a second problem. Re-porting software to a new platform can be an expensive proposition if proper preparations and funding adjustments haven�t been made or planned in advance. Minor software-development efforts can cost in the millions of dollars and often far exceed the cost of procuring the new hardware component.

    Give PMs �cradle to grave� responsibility for their systems. There has been a great deal of discussion as to whether replacement or upgrade responsibility should go to the using unit once fielding has been complete. This approach can lead to significant problems and isn�t recommended. Decentralizing of recapitalization requirements is the equivalent of herding cats. Every commander would have to plan for his or her system upgrades without being privy to or have control of external forces that might force system migration or maintain interoperability. Funds earmarked for upgrades or rebuy could easily be diverted to meet unanticipated but necessary contingencies. It�s conceivable that within a short time, tactical data communication among major subordinate commands could become tenuous at best.

    Make CTSF the Army�s single point of distribution for all ABCS functional and program-specific application software. This is important because each product requiring interoperability with ABCS may consist of a number of software packages scheduled for release over a period of years (for instance, Advanced Field-Artillery Tactical Data System Package 9, Package 10, etc.). CTSF has the ability and charter to integrate these software packages, work out the bugs, coordinate the release schedules and analyze software and hardware impact on the total architecture.

    The Army and DoD must continue to leverage research-and-development investments in the commercial sector. PMs, defense contractors and the user community must get together early in the spiral-development process to ensure all parties have a clear understanding of �threshold� vs. �objective� requirements, how realistic (achievable) they are, and the impact some requirements have on system cost. This would facilitate the identification of a system�s functionality or capability, which � due to its current lack of technical maturity � may not be realistic to integrate in the near-term but could be met by implementing a �block improvement program� approach in system development. This approach would give users some leap-ahead capability in the near-term and an objective system consistent with their full requirements in a future block upgrade after the technology has matured to the point where it�s ready for the user community.

    Conclusion

    In just a few short years, the Army has made incredible strides toward transforming into a truly lethal, responsive and relevant force for the 21st century. Network-centric warfare is here to stay and is clearly the way the Army will fight most of its adversaries in the future. The Army must continue to exploit information dominance�s incredible potential and refine systems that will keep it the world�s pre-eminent superpower.

    At the same time, we can�t forget that all these cutting-edge information systems, high-speed C2 networks and lethal sensor-to-shooter links still boil down to a soldier drawing a line in the sand and giving his or her life, if necessary, for principles established by this nation long before anyone dreamed of war as we know it today.

    The Acquisition Corps has a tremendous responsibility to develop systems that first and foremost provide soldiers with an overpowering advantage over their adversaries. The corps must balance this with solid business decisions that will gain the greatest return on invested defense dollars, both near- and long-term.

    LTC Payne�s basic branch is infantry, but he�s been in the Army Acquisition Corps since 1989. He just finished a stint as a fellow at the Army War College�s Center for Strategic Analysis, University of Texas in Austin; it was from that assignment (and experiences from his previous one) that this article was drawn. �Each year students attending this fellowship research a topic of relevance to national security and related issues,� he said. �We focus on topics and issues of current interest to military leaders and strategists, and after conscientious and critical analysis, we provide conclusions and recommendations.�

    Before his fellowship, Payne served as PM-CHS at Fort Monmouth. During that assignment, he worked with DISC4 to investigate options/strategies on recapitalizing computers and related automation hardware. Selected for promotion to colonel, at the end of July he became commander of Electronic Proving Grounds, Fort Huachuca, Ariz. Payne holds a master�s degree in public administration from Webster University and is also a graduate of the Defense Systems Management College.

    Acronym QuickScan
    ABCS � Army Battle Command System
    C2 � command and control
    C4 � command, control, communications and computers
    C4I � command, control, communications, computers and intelligence
    CHS � Common Hardware Systems (program)
    COTS � commercial-off-the-shelf
    CTSF � Central Technical Support Facility
    DISC4 � Director(ate) of Information Systems for Command, Control, Communications and Computers
    DoD � Department of Defense
    EMI � electromagnetic interference
    Gb � gigabyte
    IT � information technology
    KPP � key-performance parameters
    Mhz � megahertz
    ORD � operational-requirements document
    PM � program manager
    RAM � random-access memory
    SE&I � system engineering and integration
    TRADOC � Training and Doctrine Command

    dividing rule

    Back issues on-line | "Most requested" articles | Article search | Subscriptions | Writer's guide

    Army Communicator is part of Regimental Division, a division of Office Chief of Signal.

    This is an offical U.S. Army Site |

    04/04/12

    This is an offical U.S. Army Site |