Failure Engineering and Analysis Toolkit @EAT) - An Integrated Reliability Tool

Boston IEEE Spring Reliability Symposium April 18,1996

Philip W. Tsung RISE

8 Ninth Street, Suite 710 Medford, MA 02 15 5

Phone: (617) 391-5153

Email: PWTsung@aol.com FAX: (617) 391-8592

Abstract

Reliability Improving Systems Engineers, Inc. (dba RISE) was funded by the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) under the FY95 Small Business Innovation Research (SBIR) program to research the t echca l feasibility of developing an integrated manufacturing engineering software toollut focusing on failure analysis. The period of performance was July 1, 1995 through December 31, 1995. Philip W. Tsung of RISE was the Principal Investigator.

The purpose of the SBIR Phase I research w to determine the technical feasibility of developing an integrated manufacturing engineering software toolkit for the mechanical parts production domain. The focus was on integrating leading mechanical engineering Computer Aided Design (CAD) and Computer Aided Manufacturing (CAM) software with reliability analysis and quality tools. The title of this research is Failure Engineering and Analysis Toolkit (FEAT).

The research consisted of the following activities: obtain information on CAD/CAM software for the mechanical engmeering industry, identify reliability analysis packages and quality tools, define the user requirements, and define the technical specifications. Development of the User Requirements and Techmeal Specification documents were the primary research objectives.

Results of the research indicate that development of a comprehensive, integrated manufacturing engineering toollat focusing on failure analysis of mechanical parts is both feasible and practical. However, more research on CAD/CAM software is required. This includes obtaining hands-on knowledge of PC-based CAD/CAM systems and determining an automated capability to translate CAD/CAM files for incorporation into FEAT. Once this is accomplished, we can begm to develop the FEAT model.

The operation of FEAT will be dependent on an ability to translate and read CAD/CAM data files. Thereafter, proven and effective reliability analysis and quality assurance techniques can be performed either within FEAT itself or through commercial software packages integrated with FEAT.

Successful development of FEAT will lead to sigmficant commercial benefits. Although there are a number of software programs available, none provide “seamless” integration. A comprehensive tool that addresses failure engineering and analysis will help companies efficiently meet many of the design quality assurance requirements of IS0 9000. Moreover, this tool will provide compames with proven reliability, quality, and cost improvement techmques that they will be able to use to improve the quality of their products and manufacturing processes.

Methodology

The approach to determine the feasibility of FEAT essentially followed the path depicted below

Although this flow chart illustrates an essentially serial sequence of steps, the actual process consisted of an overlapping of these steps. Several months were spent gathering and reviewing information. However, until the User Requirements document was written, FEAT was nothmg more than a loose collection of ideas and concepts. The user requirements helped focus the work on developing the technical specifications. Of' course, during the development of these specifications it became evident that adhtional information was still needed and the first three steps in the figure above were revisited.

Several sources of information were used in performing the research presented in this report. Although textbooks are useful for well established techmques such as statistical analyses and principles of quality, a

good part of the research was dependent upon magazines, trade journals, and conference proceedings. Because of the dynamic nature of the CAD, PC, and software industries, it is obviously important to have timely information. Key journals related to the machined parts and CAD /CAM industries are:

+ Design Computing

+ + Design for Manufacturability

+ Joumal ofrlpplied Manufacturing Systems

+ + Integrated Manufacturing Systems

+ Manufacturing Review

+ Design News

4 Computer Aided Engineering

+ Computer Integrated Manufacturing Systems

+ CAD Computer Aided Design

t Manufacturing Systems.

International Journal of Machine Tools &Manufacture

Intemational Journal of Operations and Product Management

Although reliability software packages were identified through some journals, the most comprehensive source was through the Reliability Analysis Center (RAC) Home Page (http://iitri.com/RAC/). The RAC also serves as a clearinghouse for quality and reliability related materials.

Many commercial software packages were reviewed during this Phase I effort. These included CAD/CAM mechanical engineering models, CADICAM translators, reliability analysis packages, and statistical analysis software. Information obtained from manufacturers of these products was used to assess the potential Viability of integrating these products into the FEAT model. Many of these companies provided us with demo disks or actual copies of their sofhvare so that we could fully evaluate the features of their products. Once sufticient knowledge was obtained from literature searches and software review, we turned our focus towards writing a User Requirements document and a Technical Specification document.

Results

Research was conducted in order to complete the three major tasks as stated below.

Task I : Identifi Quality/Reliability Data Sources Task 2: Determine Quality hfeasures and Reporting Requirements Task 3: Define an Integrated SofhYare Architecture for FEAT.

Task I : Identify Quality & Reliability Data Sources/hfodels

In order to complete the first task, two fundamental questions had to be answered about FEAT: + +

In what environment (Windows, UNIX, etc.) should FEAT run? HOW will various software packages share information?

It was apparent that FEAT needs to be developed for use in a Windows environment. Businesses are moving towards Microsoft operating systems for their networking needs. Windows NT and Windows 95 will be the dominant operating systems for the next year. The release of Windows NT with the Windows 95 shell is expected within the next year.

As it moved from mainframes to workstations, CAD software is now moving from the more costly workstation to the less costly PCs. As the power of the PC continues to grow, this trend will continue and probably accelerate.

The “P6” Intel’s powerful successor to the Pentium processor, will further blur the line between PCs and workstations. Sometimes called ‘>personal workstations”, nau hybrid machines oSfer serious computing power, built-in networkrng. and expandability like workstations; but with off-the-shelf components, the Windows NT operating system and more PC-like prices. And with Windows, these machines will be able to run a huge variety of software.

“The engineer is really going to be able to have a single device on the desktop that runs all ofice and engineering applications - at PC prices with high-end worhtation performance, ”says Dana Lajoie, technical director at Digital Equipment Corp. ’s SofhYare Partner Group for Technical Applications, Marlboro, MA. Ref. I]

Also, there is a new beginning for CAD, as CAD users are looking to customize the software for their internal processes and Windows makes that customization easy mef. 21. Further evidence of the importance of Windows is the interest by CAD software companies in Object Linlung and Embeddmg (OLE), which is dxcussed later in this section.

A FEAT design issue was whether to develop this product for Windows or UNlX / AIX operating systems Because of the trend in CAD software and the reality that design engtneers will almost solely be the individuals to have easy access to workstations, FEAT needs to be developed in the Windows environment.

Additionally, not all companies can af€ord or even need the power of workstations. There are numerous small machme shops, molding companies, etc. that are looking to establish their own quality processes, but not invent new ones. T h s type of user is the ideal can&date for FEAT.

Given that FEAT will operate in a Windows environment, the method of exchanging data between applications must be determined. Typically, most applications accept ASCII files for input. However, t h s requires the user to export data from one application to a file and then to import it into another application. usually, a non-trivial amount of time is spent dealing with the formatting of the output and the input in order to get the whole process to work. For FEAT, the preferred method of accessing data is Open Data Base Connectivity (ODBC).

Applications can use ODBC dnvers to transparently access numerous PC databases (such as Access, Paradox, FoxF’ro, BASE) or enterprise systems (such as Microsoft SQL Server, SYBASE, or OUCLE). There are several ODBC dnver packages available on the market to work with C, Visual C++, Pascal, and Visual Basic programming languages.

Essentially, the ODBC driver manager with the database driver allows data to be shared between the application and the database table. While ODBC allows an application to acquire data from a data source, Dynamic Data Exchange @DE) and Object Linking and Embedding (OLE) provide an even more powerful mechanism for applications to share and access data.

Dynamic Data Exchange @DE) enables two applications to exchange data with each other. For example, you can link a Microsoft Access table or query into another application that supports DDE. Each time this link is updated from within an application, the most current data from that table is retrieved. Updates to that table can also be sent from the application to the linked table.

You can compare a DDE communication to a typical conversation between two people. One person gets another person’s attention. Either information is provided or a question is asked (i.e. a request for information). This ddogue continues back and forth until the conversation ends. It is useful to consider that a link has been established between the application.

Object Linking and Embeddmg (OLE ) is an industry standard which applications can use to make their OLE objects available to external development tools, macro languages, and other applications that support OLE. OLE allows objects from one application to be embedded into or linked to another application.

Also, three standards that define how CAD drawings are represented and can be transferred fiom one package to another are:

+ + Data Exchange Format @XF)

+

International Graphical Exchange Specification (IGES)

Standard for Exchange of Product Model Data (STEP)

Translators based on these standards will be an essential part of FEAT, as CAD/CAM data files will need to be translated for use within FEAT and other software packages integrated with FEAT. Several translators have been identfied during the course of this research.

In summary, ODBC, DDE, OLE, and CAD translators are the tools whch will allow FEAT to exchange data with other applications and data sources.

Tmk 2: Determine Quality Measures and Reporting Requirements

In general, there is a limited number of quality and reliability Windows-based s o h e packages suitable for FEAT. Of the Windows based quality and reliability related packages, very few are ODBC compliant or share their objects through DDE or OLE. Some packages claim to provide a CAD interface, but actually offer no more than an ASCII import feature. The primary quality and reliability packages whlch appear to be suitable for inclusion in FEAT are SPC packages.

This section describes the reliability and quality modules that should be incorporated into FEAT. Ideally, such tasks as reliability predctions would have been implemented via third-party software packages to which FEAT would interface. The focus on this section is to describe the benefits of these models and the motivation for inciudmg them in FEAT, not necessarily on how they are implemented.

Reliabilitv Prediction

Based on existing failure data on similar parts, reliability prediction provides estimates of the reliability of assemblies and their components. These reliability predictions are especially useful for determining design trade-offs and to verify that parts are not being over-stressed in their applications. The three most common procedures for conducting reliability predictions are: MIL-HDBK-2 17 [Ref. 31 , Bellcore [Ref. 41, and “Handbook of Reliability Prediction Procedures for Mechanical Equipment” [Ref. 51.

MIL-HDBK-217 provides failure rate estimates for electronic components based on the application conditions such as voltage, wattage, temperature, etc. The typical scenario is that a reliability prediction is obtained for an electronic assembly based on the failure rates of its components. This handbook is based on data compiled by the Department of Defense.

An alternative to MIL-HDBK-217 is the Bellcore model whch stands for Bell Communications Research. Bellcore used MIL-HDBK-217 as a basis for its modeling approach and was developed for use on commercial products.

However, both MIL-HDBK-217 and Bellcore focus predominantly on electronic components. The state of mechanical reliability prediction is not as mature as electronics reliability prediction, primarily due to the increased difficulty of obtaining failure data on individual mechanical parts. However, there are two generally accepted approaches for mechanical reliability prediction: The Handbook of Reliability Predction Procedures for Mechanical Equipment and NPRD-3. The Handbook of Reliability Prediction Procedures for Mechanical Equipment provides an approach similar to MIL-HDBK-217 and addresses such devices as solenoids, springs, valves, pumps, gears, and motors. Additional mechanical failure rate data is provided by the Nonelectronic Parts Reliability Data (NPRD-3) [Ref. 61, a document provided by the Reliability Analysis Center, a Dept. of Defense sponsored engineering center based in Rome, NY.

Fault Tree Analysis

Fault Tree Analysis (FTA) is a top down approach where a high level fault is broken down into the faults that will cause it to occur. The result is a tree structure that provides a graphical representation of how component failures, human errors, etc. mamfest themselves as system faults. Probabilities can be assigned to these basic events and the probability of hgher events occurring can be calculated. In addtion to identlfylng critical points of failure, FTA provides a concise format for defining &agnostic and troubleshooting aids.

Failure Mode, Effects and Criticality Analysis

Failure Mode, Effects and Criticality Analysis (FMECA) is a bottoms-up approach to identifying system failures, their effects on the system, and the criticality (e.g. safety hazard, machinery damage, etc.) of the event. FMECA has gained widespread acceptance as a design and process reliability improvement technique.

FRACAS

For those users that have a Failure Reporting, Analysis, and Corrective Action System (FRACAS), an effective use of this data is to perform a reliability growth analysis. This analysis uses all existing failure data on a product or process and estimates the rate of reliability improvement (i.e. growth) over time. The two most commonly used models are the Duane model and the AMSAA model.

Statistical Modeling and Analysis

The statistical capabilities of FEAT shall include those features that a typical engineer will be capable of performing and only those features that would be needed to perform a quality or reliability related analysis. These features are distribution fitting, linear regression, reliability growth modeling, proportion defective, and tolerance limits.

FEAT needs to provide routines to fit several common distributions to complete and censored data. The choices of distributions must include: exponential, Weibull, lognormal, normal, beta, uniform, and Raleigh.

In the majority of cases, the available failure data for a part consists of failure times and the times of the surviving parts. In order to accurately estimate the mstribution of the failure times, it is important to also include the times of the survival parts. Except for the exponential distribution, it is not a simple procedure to use the survival times. Thus, a technique called maximum llkelihood estimation (MLE) is used. This estimation method determines the most “likely” parameters of the assumed model that would provide the existing set of failure times and survival times. MLE also allows statistical tests to be conducted in order to determine if one model is better than another model.

FEAT needs to provide a generic multiple linear regression package. Since most spreadsheets (such as Excel) or the StatMost product previously identrfied provide a regression package, a specially created regression module does not need to be developed for FEAT.

Tolerance Limits

Despite efforts by the quality community to get companies to move away from pasdfail criteria and to look at the entire distribution, parts are still defined by nominal values and tolerances. Parts with attributes outside of these tolerances are considered defective. Hence, there continues to be a need to determine the fraction of a population out of specification based on a sample. More importantly, one wants to be able to bound the fraction out of specification. FEAT needs to provide this capability as well as the ability to calculate tolerance limits. Essentially, tolerance limits are limits within which a specrfied percentage of the population will lie. These limits are based on a predetermined confidence level.

Sampling Plans

Sampling plans, statistically derived or not, are used to acceptlreject a product. FEAT needs to be able to provide sampling plans to users in a way that the “mystery” is removed. The mystery or perhaps just the confusion comes from the fact that a ‘‘good” product may be rejected and that a “bad product may be accepted. The sampling plans need to be provided with the correspondmg Operating Characteristic (OC) curves that define the risks involved in any sampling plan.

Statistical Process Control

Statistical Process Control (SPC) is a simple approach that a manufacturing company can use to track and report on the stability of their manufacturing processes. The key purpose of SPC is to identlfy when something in the process changes and appropriate corrective action can be taken. Unfortunately, the majority of companies collect volumes of data which are only examined in order to “put out the latest fire.” Given that the databases are defined and updated, FEAT needs to be able to provide the latest control charts for any aspect of the process. In addtion to SPC charts, useful measures include Cp and Cpk.

Simulation

A generic simulation package will be included in FEAT. This package will allow the user to perform “what-ff’ analyses by defining functions of random variables and their respective distributions. The user will be able to define variables and operators with a few clicks from the mouse, For each variable the user will be able to spec& the underlyng distribution. The functions shall be simplified as much as possible

based upon the known relationships between the random variables. In some cases it will be possible for FEAT to provide an analytical solution.

Cost of W i t v

Businesses pride themselves on being able to make sound financial decisions. However, when it comes to makmg quality and reliability decisions, decisions are often made on an almost emotional or plulosophical basis rather than a sound financial basis.

FEAT will provide a Cost of Quality module based on the guidelines grven in pef . 71. Cost of quality is broken down into the following four categories:

4 Cost of Prevention (e.g. Quality personnel, training, audits, and calibration)

+ Cost of Appraisal (e.g. acceptance testing inspection, product audits, and analysis of data)

+ Cost of Internal Failures (e.g. scrap, rework, re-inspection, analysis of defects)

+ Cost of External Failure (e.g. complaint adrmnistration, customer service, product returns).

The last two costs identified above can be determined within the FRACAS module. Additional tables would have to be joined to these tables in order to capture or calculate the necessary information such as material and labor costs.

Task 3: Dejhe an Integrated SofiWare Architecture for FEAT.

FEAT will enable the user to read CAD/CAM data files, to access ODBC compliant databases, and to use objects via DDE and OLE. With this information FEAT will facilitate the determination of quality and reliability information such as the identdication of failure modes, part reliability predctions, and process yield estimates. FEAT will allow users to exchange information among several software packages in order to perform preventive, predlctive, and proactive tasks such as Statistical Process Control (SPC), Fault Tree Analysis (FTA), and Failure Mode, Effects, and Criticality Analysis (FMECA), as well as reactive tasks such as a Failure Reporting, Analysis, and Corrective Action System (FRACAS).

These requirements for FEAT will be accomplished by adhering to the following ground rules.

+ + +

All software will be implemented in a modular fashion

All data will reside in ODBC compliant tables

All FEAT objects will be accessible through DDE and OLE.

A key element in FEAT will be the Failure Mode entity. Failure Modes appear in Fault Tree Analyses, FMECA, and FRACAS. In order to take advantage of this commonality FEAT will have to make a single Failure Mode table available to each module. For example, the FRACAS module should be linked to a separate Failure Mode Table which can be modified to include a Failure Mode ID. Thus, any changes to the failure mode itself will “ripple” through the FRACAS system (i.e. all references to a particular Failure Mode ID will be automatically updated). This same Failure Mode Table will be utilized in the implementation of the Fault Tree Analysis and FMECA functionality in FEAT, as once agam, the Failure Mode entity is used in both processes.

The figure below depicts the FEAT model and its elements. The data flow conceut relies on developing a mechanism to read CAD/CAM data files and then using FEAT to determine failure related information, such as failure mode identification. uarts reliability prediction, process vield estimates, and corrective action determination. That is, specific CAD/CAM data will be translated and read by FEAT, which in turn would be used for a number of reliability and quality analyses (both within FEAT and with the many software packages integrated with FEAT).

.. .

.. .

\

Conclusions and Recommendations

Conclusion #I: FEAT is both feasible and practical.

Results of the Phase I research indicate that development of an integrated manufacturing engmeering software toolkit such as FEAT is both feasible and practical. A key feature will be FEAT’S ability to read CAD/CAM files and then translate the data for use within FEAT, as well as a number of commercial software packages that are integrated with FEAT.

Conclusion #2: FEAT needs to be structured in a modular fashion.

Not all users of FEAT need the full menu of options that FEAT will provide. For example, FMECAs and Fault Trees are useful tools for assembly or system development, and a process FMECA could be conducted for any manufacturing company. However, they would have limited use for machine shops. Ths modularity will allow certain features to reach the marketplace prior to all features being completed. Also, a customer will only want to pay for exactly what he or she needs.

Conclusion #3: In order to provide regression analysis, FEAT should interface with Excel and StatMost.

Mcrosoft’s Excel is an industry leadmg spreadsheet with powerful built-in regression tools. Datamost Corp.’s Stath4ost for Windows product provides numerous statistical functions that are well suited for the FEAT requirements. Also, Excel and StatMost are fully ODBC compliant.

Recommendation #I: Inquire to companies with DOS based reliability software about when Window versions, in particular ODBC compliant versions, will be available.

If these companies want to sell their packages to new companies, they will undoubtedly have to migrate their packages to Windows. It will be important for RISE to be aware of these plans so that the possibilities and implications of integrating these tools into FEAT can be addressed. This issue is particularly important for Fault Tree Analysis and FRACAS s o h e . At present it appears there are no suitable Windows packages on the market. It may be necessary to write indwidual interface modules to use the data from existing DOS based reliability tools.

Recommendation #2: Hands-on kdowledge needs to be obtained on PC-based CAD systems and their file formats.

m l e FEAT is not intended to be an add-on to existing CAD systems, companies will want to use their existing data and files with any future products. It is important that RISE understands how these tools work from their capabilities to how the user interfaces with the C A D tools. The following CAD packages should be reviewed: ProEngineer, Autocad (or Autodesk Mechanical Desktop), and DesignCAD.

Recommendation #3: Translators for workstation and mainframe CAD system files need to be identified and incorporated into FEAT.

Since FEAT is intended for use on the IBM PC, numerous workstation and mainframe CAD systems were only superficially examined in t h s research. The incorporation of such translators could increase the marketability of FEAT.

Recommendation #4: The requirement to work under Windows 3.1 and Windows for Workgroups needs to be re-examined in favor of Windows 95.

It is expected that in the next year most WindowsIWindows for Workgroups users will upgrade to Windows 95. Windows NT is already the operating system of choice for many businesses. The requirement of FEAT workmg under Windows and Windows for Workgroups is based on the current state of a€€airs. Dropping these two versions of Windows would greatly s imple the validation process and allow the 32-bit features of Windows 95 and Windows NT to be used.

Recommendation #5: The STEP standard needs to be addressed.

While the STEP standard is currently under development, it is anticipated that within a year or two it will be approved as an industry standard and common language for product data definition. FEAT must account for STEP data files along with IGES and DXF formats.

References

1. “Technology Forecast 1996,” Design News, January 8, 1996, pp. 78-90.

2. “ A New Beginning for CAD”, Design Nays, January 22, 1996, pp. 46-54

3. MIL-HDBK-217F, “Reliability Prediction of Electrical and Electronic Equipment”, Department of Defense, 199 1.

4. Bell Communications Research Report TR-NWT-000332, Issue 4, September 1992.

5 . “Handbook of Reliability Predction Procedures for Mechanical Equipment”, Document DTRC-90/ 10, Department of Defense.

6. “-3, ‘Nonelectronic Parts Reliability Data”, Reliability Analysis Center, Rome, N Y , 1991

7. J. Cullen and J. Hollingum, Implementing Total Quality, Springer-Verlag, New York, 1987 pp. 95- 110.