Designing for forward and backward compatibility is key to managing obsolescence

Story

October 14, 2014

Michael Carter

IXI Technology

The military and defense community struggles with the issue of obsolescence as it works to accept new designs for COTS products. This environment requires suppliers, especially smaller ones, to innovate or die. But the outlook is not bleak for companies that are able to produce products with high value to the defense market. In an era of declining budgets, service-life extension of systems is critical to maintaining the operational availability of every ship and aircraft.

When a component or technology is forecast to go out of manufacture, technology suppliers typically provide ample notice to users relative to the date the item will no longer be available. Company management must be made aware of these situations and develop a plan to mitigate such an event. Product plans and development schedules must take into account the design-cycle time and the date that the item will no longer be available.

If there are no direct replacements for a particular item, the solution is to design out the obsolete item. In this case, users must be notified of the situation and given the opportunity to purchase the old design prior to the product’s end of life (EOL). Users need a specific date past which the old design will no longer be available along with a schedule for when redesigned prototypes will be available for testing and general production release. Every user will require a different solution; few will simply accept a redesign with open arms.

Such is the nature of commercial off-the-shelf (COTS) technology. To mitigate user problems, the goal of a supplier should include designing a new product that is forward- and backward-compatible in performance, has the same physical size as the previous iteration, and contains the same connector interfaces as the design that is becoming obsolete. However, not all, if any, of these design goals may be achievable when addressing obsolescence.

To replace the notion of “obsolescence,” a set of systematic evaluation, design, and review processes must be generated and implemented. Design standards and practices should be continuously evolving, with the goal of meeting performance requirements, providing a long product life cycle, reducing design-cycle time, and improving manufacturability and testability.

Stringent design and development procedures

The use of robust design processes is well-suited to meet these objectives. Product design and development procedures and processes are complex and must establish design requirements for, or to meet, the following:

Market requirements
Performance specifications
Design-process documentation and control
Regulatory requirements
Thermal performance
Environmental performance and qualification
Hardware and software qualification
Design reviews
Material and manufacturing cost
Mechanical design, including geometric dimensioning and tolerances
Tooling
Design for mechanical assembly
Printed circuit board design and review criteria
Component selection and analysis
Component footprints, orientation, and placement
Printed circuit board assembly manufacturability
Printed circuit board assembly design for test
Systems test
Packaging

Company management has responsibility to manage the cost, schedule, and performance requirements of all design efforts. The development and management of budgets, activity schedules, and design verification is mandatory for successful design processes. Design-cycle time can be reduced and on time release can be improved by implementing “Figure of Merit” and “Dynamic Cycle Time” reduction techniques during the engineering phase.

Although not an approach to be taken without adequate customer notification, one way COTS suppliers can manage obsolescence is by forcing new technology adoption. Even with advance notice and information, many users do not plan for the loss of supply of products affected by obsolescence.

Examples of users’ responses who are unhappy about potential or upcoming loss of product supply can include:

“No, we won’t allow it.” “Buy all the items going end of life and stock them at your expense for us.” Sometimes it’s “Buy all the items going end of life, build completed boards and systems, and stock them for us at your expense.” Or perhaps “Buy the quantity of items going end of life we need for our program and stock them at your expense for us.” Some have heard “Buy the quantity of items going end of life we need for our program, build boards and systems and stock them at your expense for us,” Or the ever-popular “Why can’t you control the supplier?”

Obviously, these responses are from users who have not planned for the loss of supply. COTS product and system suppliers are faced with the obsolescence dilemma every day. Beyond advance notice and specific dates of availability, methods used to mitigate negative impacts include the purchase of the technology going EOL based on historical usage, forecast demand, and customer input.

Unfortunately, real-world experience shows that many users are unable or unwilling to provide a forecast for future demand. In addition, few are willing to buy components and associated products that have items going EOL.

Nonetheless, suppliers who make new design prototypes available for test and evaluation by users at specified dates will give the users the opportunity to integrate the new design into their products and systems. The time required to evaluate the new design is dependent on the magnitude of design and configuration changes.

Those who work with suppliers on obsolescence issues will be ahead of the curve, while those who do not will see a negative impact. Ultimately, when supply is gone, it is gone for good and users will be forced to adopt the new technology.

New designs cost money. Who pays for the new design? The COTS supplier does in most cases. The decision to start a new design to replace obsolete technology is one of economics. If development costs are not supported by an adequate return on investment (ROI) a supplier may decide to discontinue the product or system entirely.

Consider the following example: A major FPGA supplier announces the EOL of an aging FPGA that is used by a COTS supplier. The COTS supplier’s engineering department develops a plan, including cost, schedule, and performance elements to replace the FPGA. The cost of the design is determined to be $2 million.

The COTS supplier’s sales and marketing departments determine the total demand for the product to be $2 million the first year after the new product is released, $3 million in the second year, and $4 million in year three. Sales in year four are forecast to be $3 million, with sales in decline in the years thereafter.

The operations department of the COTS supplier determines the total cost of goods sold of the product to be 80 percent of the sales price (see Table 1).

Table 1: Example ROI of an aging FPGA.

(Click graphic to zoom by 1.9x)

In this example, the ROI is over three years. Because of the unacceptable ROI, executive management should not approve the design.

Development costs must be supported by an appropriate ROI and are amortized as part of cost of goods sold. If the ROI of a part development is two years or less, designing out obsolescence has a chance.

COTS obsolescence is increasingly migrating to the adoption of platform architecture but not necessarily in legacy configurations. As older systems are not supported, or even available, military program executive officers and contracting officers are looking to COTS technology for systems emulation through hardware and software. Recently, legacy-system emulation and data translation is being driven to be a complete software simulation running on new generation servers.

Obsolescence in COTS technology is not slowing down; it is speeding up. COTS suppliers in the mainstream can be proactive in addressing its impact while supporting both users and the military and defense industry.

Michael Carter is the CEO of IXI (formerly Sabtech). He is an industry veteran with more than 30 years of technology and product-development experience. He has developed systems and technology employed in early warning, fire control, navigation, embedded computing, servers, data I/O, communications, and power control. Readers may reach him at [email protected].

IXI (formerly Sabtech) 714-692-3800 www.sabtech.com