by David Johnson
Building complex military systems from commercial off-the-shelf (COTS) components is a great idea, but does it work? The problems of trying to support long lifetimes of military deployment with commercial technology that can go obsolete before it has seen its first day of action are all too evident. The battle takes place not only with system integrators who deploy commercial boards, but also with board manufacturers who base designs on commercial integrated circuits.
For the board manufacturers, there are endless compromises to make with performance and lifetime. Do you want the best performance and richness of functions, or do you want to choose components with a chance of staying around for a while? It's a competitive market out there, so underspecifying a board could mean missing sales targets. Customers can clearly compare your clock speed or density of memory devices, but the issues of long-term support are much harder to quantify, and not everybody is going to be convinced that they can accept a lower specification for a longer lifetime. Getting the balance right is critical for long-term success as a supplier.
Some systems integrators believe the jury is still out on the whole COTS concept. Who will pick up the pieces if problems occur and repairs become impossible? The original manufacturers will have probably long since moved on. If they are still in business, they'll probably offer a new upgraded solution based on the latest operating system, form factor, and bus standard, yet it is unlikely that this will be a drop-in replacement.
Expecting COTS to be a plug-and-play solution to complex problems is just as naïve as completely ignoring the benefits of exploiting commercial technology. Not surprisingly, the skill is to recognize the opportunities, identify the risks, and manage the process. In practice, this means that developers can achieve a robust design when the requirements are sympathetic to the available solutions.
Stretch the requirements too far from the available technology and suddenly it's not an off-the-shelf solution. At best this will mean nonrecurring charges, assuming the vendor is even willing to offer a special, but more significantly it takes the product out of the mainstream, which potentially makes long-term support difficult. Staying within the core product line of a vendor is the best chance of ensuring longevity of supply.
One of the key considerations when designing board-level products is the use of multisourced components. The ideal situation is to have at least two sources to enable component interchangeability and thereby reduce the risk that one obsolescence problem will sink the ship.
Although this goal remains noble, competitive products often use specialized devices that probably have no second source. In this case, it is vital to have a roadmap to new devices that retain backward compatibility. Moving from boards to systems, an integrator looking for COTS solutions will also be concerned about open interfaces for hardware and software that offer the opportunity of replacing a module with an equivalent capability. Industry-standard interfaces are obviously a core concern here, but even where specialized capabilities are needed, consideration should be given to how these may be implemented using open standards building blocks.
To respond to these challenges, the concept of COTS is evolving and a new era of openness is emerging. COTS isn't just about being off-the-shelf, it's about being open. For a COTS supplier, being open means using industry-standard interfaces as a starting point, but it must also extend to sharing detailed information on all aspects of the solution — schematics, road map, inside engineering knowledge, software interfaces and, under some circumstances, even the supply of source code. The relationship must be less adversarial and more like a partnership in which the supplier contributes to the architecture of the client's solution.
For a COTS user, in contrast, being open means being prepared to adapt your requirements to the constraints that existing COTS solutions impose, which involves allowing insertion points as the technology evolves. Blindly constructing requirements without regard to existing standards and commercial solutions may, in the extreme case, not only preclude a COTS solution, but also force an uneasy "enhancement" of a product or standard that complicates long-term support and technology insertion.
The COTS user has a responsibility to look forward to see where technology is heading. For long-term military programs, development and production time frames easily can extend to 20 years or more. Reliable predictions so far out are impossible, but designers can take measures to identify technologies that are likely to change and ensure that they are not excessively built-in to the fabric of the solution.
A principle that is helpful here is "loose coupling" in which modules or subsystems of a solution connect with a high-level, well-documented interface that forms a convenient insertion point for technology enhancements.
Many systems integrators find that involving potential suppliers early is the most effective strategy for successful COTS applications. Interaction at the start of the design cycle is essential in ensuring that the supplier can understand not only the program requirements, but also the technical limitations of existing products.
This is not to say that designers must compromise the functional requirements of a final system. Solving the same problem in a different way can have a huge impact on the applicability of commercial technology and the sensitivity of the solution to future technology changes. A thin veneer of software on top of an industry processor card, for example, is probably better than paying customization charges to the card supplier.
Likewise, employing a proprietary graphics language for displays is generally less attractive than using an open graphics library, even if that library is overkill for the application, relatively inefficient, and requires high specification hardware. In this situation, paying the additional cost of the hardware buys insurance against obsolescence of the proprietary product, and avoids being locked in to one vendor.
In summary, there is a lot more to successful deployment of COTS than first appears and not all military COTS projects will be successful when measured over the lifetime of the project.
Designing with COTS clearly doesn't stop with choosing COTS components. It is important to choose suppliers who understand your business and time frames for support and maintenance. These companies should be open, sharing information when it's needed during design, advising on architectural tradeoffs that keep your products aligned with their product road maps.
Users of COTS products have a responsibility to examine their architectures with future technology insertions in mind, localizing any vendor dependencies and building in well-defined interfaces that can support future technology refreshes. If specialized data formats or interfaces are required at the external ports, building these internally from standard interfaces and components will ensure the most robust and maintainable architecture. And, yes, it may be necessary to pay a little more for those benefits but the long-term paybacks will make it worthwhile.
David Johnson is a senior product manager at Primagraphics in Royston, near Cambridge, England. Readers can reach him by e-mail at [email protected] or online at www.primagraphics.com
