Is a new reliability standard really necessary?
To The Editor:
We are reliability consultants and have been in the business over 20 years. After reading John McHale's article "TRENDS: Board vendors push for new COTS reliability standards" in the May 2000 issue of Military & Aerospace Electronics I was alternately cheering and shaking my head.
We do need a new reliability standard without a doubt! Unfortunately there is none on the horizon that I can see. I recently did some research into the available predictive techniques. They fall into two main categories: one that gathers statistical data on components and uses an Arrhenius formulation to translate the data to the temperature of interest ('217, Bellcore, and many others); the other uses the "physics of failure" approach mentioned in your article.
The main problem with the first group is they rely on some "entity" to gather and translate the base data. They are, by definition, always out of date. The main advantage is they can give you a handle on system reliability, since it is assumed the errors made at the component level are statistically averaged over a large population and the end result is fairly accurate.
The big disadvantage of the physics of failure method is the immense amount of data (some of it considered proprietary by the component manufacturers) that is required for each component in the assembly. For a given board, only a small area can be analyzed with the analytical tools available. Because of this, systems analysis is not a consideration.
Your article also addresses HALT. This methodology is the brightest light on the reliability engineering horizon today. HALT addresses "robustness" or design integrity. It does not, as suggested by some of your sources, predict reliability. We suggest our clients develop a HALT program as one of the first steps in designing reliable products. It can be applied early in the development cycle and give the designer relevant feedback. We have seen problems uncovered in HALT, not addressed, come back to haunt the company in terms of field returns.
We perform many reliability predictions for our clients to either MIL HDBK 217 or Bellcore. What we add for our clients is relevance. We use, the greatest extent possible, the test data provided by the component manufacturers. Almost every component manufacturer will put a new component through a "Qualification" process. One of the parts of the process is a High Temperature Operating Life (HTOL) test. They also have ongoing process monitor reliability tests. This data is available on the Web or upon request from the manufacturers. From these sources we gather data to include in either a '217 or Bellcore prediction.
With the release of '217 F, the creator Seymour Morris said that the standard should be used as a guide and the user should incorporate as much actual data as possible. We have taken him as literally as possible to give our clients a prediction the gives them a view of future performance that is still a '217 or Bellcore prediction but overcomes the big disadvantage of these methods: currency.
I would advise your readers to use the incredible amount of reliability test data available instead of waiting for a new standard that may never come. We publish as many of these data sources as possible at our Reliability Help Desk website (sea-co.com).
Peter Bachant
President
Systems Effectiveness Associates Inc.
Norwood, Mass.
Avionics designers are in need of a comprehensive open-systems policy
To The Editor:
We enjoyed reading Mr. J. R. Wilson's survey on Avionics in your April 2000 issue describing the issues regarding the transition process of military avionics to commercial electronics. The article provides valuable information of the problems faced during the transition process as a function of time. However, the article didn't clarify that a comprehensive open-systems policy, which relies on commercially available single-board computers (SBCs), could solve the commonality problems as well as the RAH-66 Comanche helicopter computer problems mentioned in the article. We will refer to several issues mentioned in the article.
1. Lengthy military design and procurement schedules lag behind commercial design and production cycles and accelerating component obsolescence.
Component obsolescence rate and military design cycle time are real challenges for modern military design processes. In the past this was true, since in the design process systems designers selected and used components as building blocks. Both issues can be solved entirely by adopting an open-systems policy. Usually, in an open-systems approach, designers select SBCs as building blocks and integrate them. Thus, dealing with components' obsolescence and lengthy military design are avoided.
2. F-22 commonality issues and Comanche computers and commonality versus open-systems attributes.
According to the Military & Aerospace Electronics survey, the U.S. Department of Defense-mandated commonality (JIAWG) has been tried and has not been successful in the case of the U.S. Air Force Lockheed Martin F-22 jet fighter and the U.S. Army Boeing-Sikorsky RAH-66 Comanche armed scout helicopter. In our opinion, the reason for the failure is the fact that open systems based on SBCs has not been used. Commonality is one of the features of open systems. But open systems have additional attributes not included in commonality, e.g. compliance with commercial, widely accepted standards. The Comanche computers rely on commonality, but not on open systems. The selected board format is SEM-E, which is a military-standard board configuration. Usually SEM-E boards are not off-the-shelf items. Open-systems SBCs are widely available off-the-shelf items common in the commercial market. Usually, compatible SBCs are available that comply with the same standard. The standards are NGS (Non-Governmental standards), widely accepted by the industry. NGS are updated by consensus. SBCs are currently developed, manufactured, marketed, updated, and maintained by commercial companies.
In order to have an expected low-life-cycle system costs that use robustly designed systems that are significantly less vulnerable to processor obsolescence than conventional designs, We would suggest basing system designs on SBCs as part of an open-systems policy, which would redefine processes such as design, maintenance, and technology insertion.
This policy should redefine the designer's task, from board designers to system integrators, using boards as building blocks. It also would help select an adequate SBC configuration (VME, PCI, Compact PCI, etc.), according to project requirements and organization policy.
Additional considerations might include commercial mainstream, number of manufacturers, SBC diversity, market acceptance, market trends, cost, multiprocessing capability, packaging, packaging density, maximum transfer rate, power, computing power, power consumption, driving capability, and loading.
In this case, the end-user is supplied with SBCs based on the latest available state-of-the-art processors compatible with earlier processor designs, with practically no research-and-development costs, no R&D risks, no integration costs, no integration risks, and no timetable delays.
Ruggedization might be associated with additional R&D cost, R&D risks and timetable delays, but they represent only a small fraction of the expected savings.
Improved performance (e.g. additional computing power and higher density/ higher memory density), as well as significant savings could be achieved if boards are purchased as required and not inventoried for later use.
Designers should establish a methodology and select a compliant computer-aided design tool, whose main purpose is in managing and controlling the interfaces and compatibility issues, rather than configuration management and control of the configuration items. The objective of the policy and methodology is to facilitate management of complex compatibility issues related with different technological implementations, including scalability. In this case, scalability involves different configuration items, functionally compatible and interface compatible, having different parametric features (e.g. complexity, computing power, power dissipation, drive capability, and loading).
Within the recommended open-systems policy, designers should establish a comprehensive SBC obsolescence-oriented policy, which will result in life cycle cost savings.
Usually, in complex systems there are several different levels of computing power requirements: electronic warfare, image processing, advanced signal processing, radar signal processing, autopilots, navigation and servo control loops. With advancement in processor performance, if required, older installed SBCs could eventually be substituted for state-of-the-art SBCs, with improved performance processors having higher computing power.
The reason for the change might be maintenance (repair/ logistic support in case of SBC poor availability or high cost), or performance upgrade, if the older SBC performance is not sufficient. The replaced SBC could be used in other subsystems requiring less computing power SBCs (application of reusability paradigm of open systems). The scenario mentioned above might occur only in open systems, which uses compatible hardware and software, and where "mix and match" or "plug and play" might be applied.
The above scenario is an example of improved combat readiness and improved investment protection for installed equipment, in addition to low-cost maintenance and improved affordability for technology insertion. The savings are very high, especially when spare part cost is skyrocketing due to poor availability (accelerated obsolescence) and the forecast is worse. Compare the above-mentioned example with other alternatives
Khanan Segal,
Segal Technology Consultants
Yahud Israel
Edward B. Hakim
The C3I Inc.
Spring Lake, N.J.
