The basic components of armament systems--weapon, ammunition and fire control--are essentially the same, but vary in how they are implemented and their degree of automation. However, as simple as the basic components are, several factors create the potential for complication. Different system contractors, the increased use of electronics in armament systems and implementation of functions through software--these factors can lead to a proliferation of unique armament systems.
This proliferation creates the associated burdens of maintaining different operating systems, system component obsolescence and redundancy, paying licensing fees and having to depend on a particular contractor's unique product and intellectual property (IP).
To sidestep these problems, the Armament Research, Development and Engineering Center (ARDEC) of the U.S. Army Research, Development and Engineering Command (RDECOM) is pursuing efforts to reduce the cost of weapons development while providing greater ability to field weapons more quickly. Teams of engineers and scientists at ARDEC, in partnership with various weapon system project managers, are developing new armament systems in-house that maximize the reuse of software and hardware components to produce systems with common features, and minimize the use of unique components requiring individual maintenance.
ARDEC's success with reuse and in-house development started with a failure. A project manager (PM) at ARDEC put out a contract for a mortar fire-control system (MFCS), with ARDEC engineers helping out as part of the integrated product team (IPT). But after the contractor missed multiple milestones and was over budget and behind schedule, the PM terminated the contractor for default and handed all of the work to ARDEC.
KNOWLEDGE AND PROCESS IMPROVEMENT
Two key factors enabled RDECOM's success with MFCS and other in-house development projects: the domain knowledge built up over years of providing support to many Army armament systems (even when a contractor builds a given system, RDECOM engineers might provide assistance as part of the IPT), and Capability Maturity Model Integration (CMMI) High Maturity processes. Because ARDEC provides engineering support to many Army armament systems and has the domain knowledge for those systems, we can look for opportunities for technology refresh using developmental technologies across the domain of systems we support. For those systems that are in sustainment, we can incorporate technologies that are in development at a much lower cost and shorter time frame than just maintaining the current configuration through obsolescence management techniques.
CMMI is another enabler for ?ARDEC's Weapons and Software Engineering Center. We became the first DOD organization to receive a Maturity Level (ML) 5 rating in June 2006 and were reappraised at ML5 in CMMI V1.3 for development in May 2013. CMMI in general is about optimizing and improving processes, and Maturity Level 5 specifically is about learning from past performances; we applied this ML 5 principle to reduce the number of defects cropping up later in development, when they require more rework to fix. We leveraged mature code from past projects--code that has already been tested and successful--and optimized "within phase" verification to catch defects early.
As a result, we went from catching only 26 percent of defects in the phase they originated in, to catching 91 percent in the originating phase. Since 2005, ?ARDEC has fielded every system defect-free; CMMI processes allow us to deliver this quality at lower cost.
CONSISTENT DELIVERY
CMMI best practices have enabled several programs at Picatinny Arsenal, New Jersey, to consistently develop and deliver high-quality products that stay within cost and schedule estimates. The associated benefits related to development costs, operational and support costs, schedule and product performance are significant. One example of this can be found in the MFCS that ARDEC took over when the contractor was terminated.
We were able to avoid more than $15.5 million per system in development costs, on average, and more than 3.5 years on average per system in development time across the eight MFCS variants for the several fielded mortar systems and major components. We know how much time and money we saved by reusing software and hardware across the family of systems because CMMI processes involve documenting steps and processes very thoroughly, in addition to learning from past performances. With that documentation and a decade's experience, we know exactly how long it will take to, for instance, write a given number of lines of code, so we are able to generate a robust and accurate cost and schedule estimate. This estimate lets us calculate how much it would cost to start from scratch and what we save by starting with mature, government-owned software and hardware already developed.
ARDEC began to develop and maintain government-owned intellectual property (IP) in the early 2000s; the organization took control of the organic domain expertise and has been continually reusing existing software and hardware components and IP across multiple armament systems, including MFCS, to significantly reduce development time and save money.
In comparison, to use outside contractors to develop all the MFCS variants would cost considerably more and extend the time it takes to develop and field systems. While the government can send out a technical data package using already developed, government-owned IP, a contractor would have to spend time and money getting up to speed. In addition, contractors often prefer to develop proprietary systems, using their own IP; they then have the option to reuse it themselves, lowering their overhead costs, and the maintenance and upgrades to a proprietary system often offer the possibility of future work. More than one contractor might be involved, increasing administrative costs, at the very least.
Conversely, ARDEC has the institutional knowledge to get a system fielded quickly. Figure 1 depicts the cost and schedule avoidance achieved by numerous programs in ARDEC's Weapons and Software Engineering Center through the reuse of both hardware and software.
THE HARDWARE ANGLE
Common hardware components are used across several of the systems, and new components are introduced with backward compatibility. Identical MFCS software is used in the M113 (MFCS Heavy), Stryker and Dismounted 120mm Mortar Fire Control System, which has the capability to function in either a gun- or fire-direction-center mode with a simple user command. The weapon system software can also be used for computer-based trainers, which lowers the cost of training Soldiers on the system since the identical software and associated updates apply to both.
Figure 2 depicts the percentage of software and hardware reused during the development of the Picatinny Light Weight Remote Weapon Station and other associated remote weapon systems, also based on an in-house approach, and estimates the costs avoided by this reuse.
Figure 3 depicts cost and schedule avoidance achieved through the implementation of flexible product line architectures, standardized developmental processes and using the tactical software as the starting point to build multiple trainers--each of which would have to be built from scratch, if the tactical software from the weapon system was not reused. These architectures enable the development and reuse of modular tactical software components and the ability to "plug in" weapon-system specific content to a configurable training framework. Additionally, the ability to reuse complex and developed tactical weapon system software provides for high-fidelity training.
The cumulative cost and schedule avoidance resulting from the commonality of software and hardware across a family of armament system trainers shown here is, on average, more than $11.2 million and more than 1.7 years per system, respectively. As with the savings from the MFCS program, ARDEC is able to estimate how many dollars and years were saved because of a combination of experience, learning from past projects, and CMMI best practices.
As we look toward the future of multirole armament systems, we can continue to advance our savings using these best practice examples and CMMI ML 5 processes. We are now looking at repurposing existing armament systems to expand the target sets they currently service. We are also designing new armament systems that can manage multiple target sets previously covered by several individual weapon systems integrated on the various types of combat vehicles.
CONCLUSION
Using ARDEC's best practices and robust CMMI ML 5 processes, any government research and development agency could achieve similar results if they control government-owned IP and possess the domain experience in their specific commodity area. Even an agency that doesn't currently own any of the IP can start now on future research and development efforts by adding the appropriate contract clauses to procure government data rights or grow its organic domain expertise.
By implementing these best practices, the Army can not only reduce procurement costs, but also accelerate development of our weapon systems. Reusing software and hardware components and developing robust system-level processes is one path to acquisition success.
Social Sharing