1 / 12

NASA EEE Parts Assurance Group (NEPAG)

NASA EEE Parts Assurance Group (NEPAG). Quality Leadership Forum July 19, 2001. Michael J. Sampson NEPAG Manager GSFC/Code 306 Systems Management Office. Overview. Organization - Partnerships/International Cooperation EEE Parts Risk Assessment Relationship between knowledge and risk

Download Presentation

NASA EEE Parts Assurance Group (NEPAG)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. NASA EEE Parts Assurance Group (NEPAG) Quality Leadership Forum July 19, 2001 Michael J. Sampson NEPAG Manager GSFC/Code 306 Systems Management Office

  2. Overview • Organization - Partnerships/International Cooperation • EEE Parts Risk Assessment • Relationship between knowledge and risk • Inherent Risk • Risk Matrix • Part Level Stoplights • The MIL System • Advantages to NASA • Surprises • A Horror Story • EEE Parts Assurance • Why should NASA have guidelines?

  3. NASA HQ Code Q Tom Whitmeyer AIAA ISO NASA Centers JPL NASA JSC Partners NASA ARC David Peters David Beverly Ron Chinnapongse ESA USAF/SMD John Kaëlberg Dave Davis Associates NEPAG NASA GRC NASA KSC Mike Sampson SAE DLA & DSCC Vince Lalli Eric Ernst NAVSEA Crane Darren Crum NASDA Sumio Matsuda NASA MSFC NASA GSFC NASA LaRc Charles Gamble Greg Rose Otis Riggins EIA NEMA USAF/SMD USAF/SMD Dave Davis Dave Davis NEPAG Organization

  4. EEE Parts Risk Assessment - Risk versus Knowledge INHERENT RISK IS INVERSELY PROPORTIONAL TO KNOWLEDGE • If a part is KNOWN to be high risk, this knowledge can be used to avoid its use or take appropriate actions to move to medium or low risk • Lack of knowledge means good parts cannot be distinguished from bad • Obtaining reliable knowledge about COTS EEE Parts requires: • Expertise • Time • Vendor visits • Testing and Analysis • BIG BUCKS ONLY a LIMITED number of COTS part types can be reliably deployed in any one system

  5. Inherent Risks - for EEE Parts • Manufacturing Factors • Spec • Vendor • Maturity/Qualification Status • Knowledge of Changes • Radiation Sensitivity • These are risks inherent to the part regardless of: • Redundancy • Derating • Mission Requirements • Mission Budget

  6. Risk Levels - Inherent Factors Example

  7. EEE Parts - Risk Management • FBC means acceptance of risk • This requires definition of an acceptable level of risk (ALOR) • Risk must be managed against the ALOR • Overall ALOR for mission translates to ALORs for systems • Low risk missions may include high risk systems and vice versa • Parts must be selected based on the ALOR of the application • Parts risk is combination of inherent risk and application factors: • Redundancy • Derating • Criticality • Parts engineers can provide inherent risk independently but can only modify for application factors with application details Parts Lists for Review Rarely Include Application Details • Engineers may be pressured to modify risk assessment based on “implied” but undefined mission factors

  8. The MIL System - Advantages for NASA • Not “Dead” for EEE Parts Anyhow • Generally offers NASA most economical solution in terms of “true cost of ownership” • Typically, no additional qual or screening • Still provides majority of EEE parts used by Agency • NASA has Custodian status for most EEE parts specs we use: • Can make “Essential Comments” • Must be dispositioned to our satisfaction or can be escalated (eventually to OSD in theory) • Audit participation taken Seriously • Free specs and assistance • As Government privy to inside information

  9. The MIL System - Surprises • During NASA’s “Nap” some “surprises” initiated: • Class T • Semiconductor Power Rating • Class T for microcircuits • Essentially COTS masquerading as MIL • Enacted for commercial interests • High risk due to lack of controls and knowledge • NEPAG eventually gets wording “Not for NASA use” added • Semiconductor Power Rating • Increased by 25% on product with 15+ years of experience • Change based on theoretical analysis not problem or need • No testing to validate change is not detrimental (continued spec compliance only) • Changes in place for ONE YEAR before NASA aware • Issue still unresolved DSCC is supported by $ from depot sales so their interest is to increase business

  10. A Horror Story - Intro • Two Sources for MIL QPL Part - Orange and Blue • Orange in NE USA: QPL ~ 15yrs to date, significant NASA use • Orange sold to national corporation Y ~ 94 • Blue in SE USA: QPL • ~ 4 years until sold to Y in 96 • GIDEP Alert in 2000 • ~ 4 years until sold to T in 2000 (T has not made similar product in >10yrs) • T bought by Y in 2001!!!! • Y announces decision to shut Orange facility in March 02 except support to Blue line at T facility • Element fab (Orange design) • QPL test • NASA and USAF asked to support “streamlined qual”

  11. A Horror Story - NASA Knows • “Streamlined qual” proposed based on: • Heritage element used • Established design ( but not with same element) • Danger of loss of critical single source (blackmail) • Pre-qual MIL audit (THIS WEEK) • NASA (NEPAG) participation • USAF/SMD, Aerospace Corp (NEPAG) participation • No others except DSCC • Audit team finds: • Y has just discovered that Orange element WILL NOT FIT in Blue design without redesign (loss of heritage)!!!! • T personnel poorly trained in process • Y and T were clearly not ready for audit • If NEPAG was not participant, would we know?????

  12. EEE Parts Assurance - Should NASA have Guidelines? • Contractors have own systems • NASA cannot expect contractors to use our system instead of theirs • So why have guidelines? • To document what we think is needed • To capture our lessons learned • To document our core knowledge • To provide a consistent NASA perspective to the contractors • To preserve our Very Successful culture • To guide participants without systems (Academia etc) • High level documents can be VCSs but implementation guidelines should be NASA

More Related