Software compounds the challenges of military component obsolescence

Story

December 05, 2012

Component obsolescence in military embedded applications will become one of the epic challenges of this century as software overtakes hardware as the primary means of innovation on and off the battlefield.

Component obsolescence in military systems and products is a well-known challenge, but it has developed a relatively new twist: the rapid increase in volume of embedded software. While software has been embedded in military electronic components to some extent for decades, that trend has accelerated to a fever pitch in the past decade; more and more of the critical functionality of our systems and products depends on software. Figure 1 illustrates the dramatic increase in embedded software as measured in source lines of code in U.S. military fighter aircraft over the past several decades. Similarly shaped curves can be found in most other complex military systems and products, including all other aircraft, naval vessels, ground vehicles, C4ISR systems, and off-battlefield supporting systems.

Figure 1: Effective source lines of software code in select U.S. fighter aircraft from 1984 to 2011

(Click graphic to zoom by 1.9x)

In fact, many in the aerospace and defense industry would claim that software has long since overtaken hardware as the primary source of innovation. Software, like hardware, is not immune to issues that require upgrading or replacement of those components. However, unlike hardware, those issues tend to be of a different nature and thus require different treatment.

Hardware is like people – Software is like wine

One of the biggest differences between hardware and software components is that hardware tends to degrade with time and usage, while software remains unchanged. Given the same inputs, the software will generate the same results every time. Hardware, on the other hand, will eventually break down or stop performing to specification because of wear, corrosion, and/or fatigue cracking as it reaches or exceeds its operating life.

That is not to say that software does not contain flaws; it is just that such flaws are latent in the software when it is produced, rather than introduced over time through usage. Software is not “manufactured” in the same sense as hardware. Once a software component is developed, it can be replicated at essentially zero cost and with zero defects introduced by the automated replication process. The reliability of software components tends to exhibit a “bathtub” shape, where initial usage reveals many of these latent defects, which are then addressed through software updates, followed by a relatively long period of low defect rates, and then a growth in issues as the original design assumptions and constraints that were the basis for the software component are invalidated as the operational environment changes. Like wine, software components tend to improve with time, as more of the latent defects are discovered and addressed.

Given software does not have the tolerancing issues associated with hardware manufacturing, nor does software wear out through usage, the traditional hardware obsolescence measures such as Mean Time Between Failure (MTBF) do not have much relevance for software. So if software just gets better with age, how does it compound the military component obsolescence challenge? To answer that, we need to understand what can cause software to become obsolete.

Root causes of software obsolescence

There are three main reasons why a software component can become obsolete:

Changes in the environment the software must run in (compatibility)
Exposure of latent defects
Changes in the role and function the software must perform

Software is merely a sequence of coded instructions that governs the behavior of the hardware platform on which it executes. Software components rely on the underlying electronic component to provide the correct interfaces and behave as specified. Thus, a major factor in software obsolescence is the change in the underlying hardware platform because of electronic component obsolescence. Electronic component obsolescence is a well known problem, because of the rapid change in underlying technologies, and the relatively low volume of military procurements as compared to commercial applications. Whenever the underlying electronic components that software interacts with or runs upon change, the software must also be reevaluated and possibly upgraded or replaced as well.

A classic example of this is the Ariane 5 flight 501 in 1996, which ended in the destruction of the rocket 40 seconds after launch. The root cause of the failure was the reuse of an inertial reference system from the Ariane 4 without proper evaluation of the constraints and assumptions behind that subsystem in the context of the Ariane 5 design. The inertial reference system was reused as it was supposedly a validated and proven design. However, that system was designed for a rocket with less power and significantly less horizontal acceleration in its launch profile than the Ariane 5. A conversion of a floating point value into a 16-bit integer triggered an overflow error, causing the flight control system to crash.

Obviously, when defects are found in software components, they must be addressed. Depending on the nature of the software component and its associated hardware environment, performing such updates in the field can be as easy as downloading the update over a network connection, or as expensive as replacing an entire electronic component. The larger cost with software components is the development effort required to analyze the defect, update the design and implementation, and revalidate the component before releasing it. This cost is often larger because the opportunity for an update often leads to the third reason: changes to the role and functionality of the software component.

As mentioned earlier, software is increasingly the source of product innovation. It is a key system integration technology, and the lives of many systems are extended through software upgrades. In the current military procurement environment, where “just-in-time” approaches to spares procurement are becoming more common, any software update opportunity typically involves enhancements to extend the life of systems or extend capabilities, as well as address defects. As hardware platforms become more powerful, more and more functionality is allocated by systems engineers to software, to save weight, reduce cost, and increase flexibility. It is these properties that have led to the drastic growth in the amount and complexity of software in military systems.

Software engineering: Not just plug and play

With components other than electronics and software, dealing with obsolescence is primarily an issue of finding an alternate manufacturing source for the component. With software, as mentioned, manufacturing is not the issue; component obsolescence requires reengineering that software, whether it is to resolve a defect or to extend and enhance its functionality.

As mentioned earlier, one of the factors that contributes to software obsolescence is changes to the context that the software must operate in – both the platform and signals it interacts with and the goals and roles of the system that the software enables. This context needs to be taken into account when reengineering software components, and too often it is not properly addressed.

Rapid growth in software complexity, the need to update software components within a systems engineering context, and the intangible nature of software all contribute to the challenge of updating and maintaining software components. The same high-level language abstractions that support development of more complex software also increase the challenge of isolating defects and determining the impact of proposed changes.

Traditionally, technical data packages for software component maintenance have focused on the source code as the artifact most closely related to the final software component, with less emphasis on the rest of the software artifacts, and little cohesiveness across the artifacts. Without full traceability between requirements, design, implementation, and verification artifacts, it is too easy to miss subtle dependencies that need to be taken into account. Tactical “patching” of software component source code can lead to monolithic, hard-to-maintain software. A more cohesive, holistic approach to software components needs to be taken to properly manage their complexity. Such an approach is known as Application Life cycle Management (ALM). ALM manages all the artifacts and activities required to define, design, implement, and verify software components (and the relationships between those artifacts and activities).

Conquering the epic challenge

While the growth in embedded software is a challenge, it is also a great opportunity, particularly with the current military procurement environment, where both cost containment and strategic advantage are demanded. Software development principles, practices, and tooling are maturing and continually improving. The following recommendations can go a long way toward taming the software challenge of component obsolescence:

Take a systems engineering approach to electronic and software component development, with deliberate planning and architecting of modular components that support reuse across different systems, with well defined interfaces between components to manage the complexity. Ensure that requirements and key design decisions that drive component definition are captured and managed for the service life of the systems using those components.
Implement a holistic ALM approach to software component development, with full traceability across all artifacts and activities and consistent processes managing all aspects of development. Invest in tooling to automate and enforce ALM practices; look for systems that provide a single process engine for managing all artifacts, with strong ties to systems engineering and hardware engineering such as PLM systems. Manage the entire tool chain, including the build and release management system, to ensure predictable results when maintaining or updating software components.
Use iterative and incremental development practices to shorten feedback cycles and improve predictability and quality of component releases. Involve all disciplines, hardware as well as software, in component updates to ensure that any dependencies between components are understood and fully addressed. Implement proactive variant management to maximize reuse of components and control sources of variation such as changing roles or technologies.

With these recommendations in place, military system designers can use software to create differentiation between variants rather than hardware, with potentially lower costs and less weight and power consumption. Manufacturers are finding that designing products based on a generic hardware platform that is capable of supporting all product line variant functionality while using software to create the individual variants offers numerous advantages.

Colin Doyle is a Senior Product Manager within the ALM Segment of PTC. Colin has three decades of experience in systems engineering and software development, in fields as diverse as avionics, remote sensing, satellite communications, medical devices, precision laser systems, enterprise content management, and Application Life cycle Management. He has extensive expertise in software change and configuration management, agile and lean software development, and regulatory compliance issues. Colin has a B.A.Sc. from the University of Toronto in Engineering Science and an MBA from Wilfrid Laurier University. He can be reached at [email protected].

Stephen Denman is on the ALM Solutions Marketing team at PTC, focusing on systems engineering and integral product/software life cycle management. He has worked in software and systems engineering since 1982, in areas including weapons systems, C4ISR, flight systems, embedded software development, information technology, application development, CAD/CAM/CAE, and product/software life cycle management. Steve has BSEE and MSEE degrees from Texas A&M University. He can be reached at [email protected].

PTC 781-370-5000 www.ptc.com @PTC @PTC_Integrity @PTC_Windchill