Is your product choice ready?
To ensure the stability of components selected for a project the right questions must be asked. Will it be deployable when needed? What is the Technology Readiness Level (TRL)?
Making a product or component selection for many projects is often straightforward. You have a requirements documents listing features needed to meet the needs of your project and you head off on a search to find components that meets those requirements. Usually you will have choices between vendors and trade-offs to make to find the component that best meets your requirements. Relatively speaking, this is the easy part. But is the product or technology you have chosen really ready for deployment? Is the technology ready?
You are not the first to have run into the problem of determining the readiness of technology for use in a real product. This is an especially daunting challenge with high technology products because by their very nature, they emerge on the market scene and then evolve very quickly, often it seems, right before your eyes. Usually that data sheet you have been pouring over, studying features, does not have a specification called “Technology Readiness Level” or “TRL.” It is left up to you to determine how real and how stable the product will be at the time you will need to use it.
Fortunately for you, you are not alone. The National Aeronautics and Space Administration (NASA) created a table defining Technology Readiness Levels in a set of nine graded definitions/descriptions of stages of technology maturity. These readiness levels have been adapted by the DoD for use in its acquisition system. Table 1 presents a definition of the nine stages.
From the descriptions in Table 1, it is not a long stretch to determine where most products fit on this scale. The fact that you can obtain a functional demonstration can quickly get you to stage 6, giving you the warm fuzzies that the product is real.
Challenges with the Technology Readiness scale
When did product shipments start on this product? Knowing the date when the product first started shipping can give you a good idea of how stable the product is at the current time. If it just started shipping a short time ago, then it is likely that there are still manufacturing issues and maybe even functional issues that have not been discovered, and appropriate remedies need to be put in place.
How many copies of the product have shipped so far? This is also a stability indicator and goes hand-in-hand with the question on first shipment date. If a limited number of products have shipped, then you are at the very beginning of the manufacturing learning curve. Expect problems with complex products. You might be okay for development, but you certainly would not want to go into full production mode with your product. Expect many engineering changes to be issued if the product has not shipped in any substantial quantities yet.
How many design wins has this product reached? Design wins are an indicator of how popular the product is in the market. More design wins make it a safer bet that the product will be around for a while and that the supplier will be dedicated to maintaining and expanding the line. “How many design wins are appropriate?” is really a function of the product and the supplier, so you really have to understand your supplier in applying a decision weight to this question. You will also find that most suppliers are hesitant to go into details on the specific number of design wins, talking mostly in generalities.
How stable are the key components used in this product? Just as the product you are evaluating is a component within your own product, the components further down the supply chain can be a concern. If you have identified components that you are concerned about, you should be sure that your potential vendor has a solid game plan to address your concerns. They could be using a microprocessor that is nearing obsolescence or a chipset that you know has issues of some type.
What is the projected life cycle? Most suppliers to embedded computing markets have a policy on product life cycles. These typically rank from five to seven years, or more under a service contract. But sometimes the product is not intended for a long product life cycle. Be sure you are clear on this if a long product life cycle is important to your decision making. Your supplier should have a program and policy to address their product life cycles.
Is there a road map for this product showing its evolution and future enhancements? Road maps are key to the entire decision process. They help you determine where products in the concept and development stages are on the Technology Readiness scale. Road maps help with early decisions, and they give you clues on what to expect for future enhancements. If a product does not have a road map, that becomes a red flag that you are a test case. Beware!
Is this product the first of its kind or an evolutionary step? Where a product fits in a product family gives you other clues that help with Technology Readiness assessment. First-of-a-kind products have higher risk because they may have design issues. End-of-the-line products take on more life-cycle risk because of the potentially obsolete components. Products that are not part of a product family have migration and evolution issues that may be of concern.
Start with “stop, look, and listen”
This list of questions is just a start. Many other questions should be considered to address specific concerns relevant to your project. In a perfect world, your suppliers would put a number on the data sheet that rated the product’s risk factors, making your decision much easier. Unfortunately, that is not likely to happen any time in the reasonable future. You will still be depended on to ask the right questions and make the right decisions.
For more information when it’s time to begin or continue your VITA-based engineering project, go to www.vmecritical.com for the latest articles, Q&As, and updates on: