NONMEASUREMENT

SENSITIVE

MIL-STD-1543B (USAF)

25 OCT 88

SUPERSEDING

MIL-STD-1543A (USAF)

Dated 25 JUN 1982

MILITARY STANDARD

**RELIABILITY PROGRAM**

**REQUIREMENTS**

**FOR**

**SPACE AND LAUNCH VEHICLES**

AMSC F4542 FSC RELI

DISTRIBUTION STATEMENT A: Approved for public release; distribution
unlimited

DEPARTMENT OF THE AIR FORCE

Washington, D.C. 20330

MIL-STD-1543B (USAF)

Reliability Program Requirements for Space and Launch Vehicles

1.  This Military Standard is approved for use by the Department of the
    Air Force, and is available for use by all Departments and Agencies
    of the Department of Defense.

2.  Beneficial comments (recommendations, additions, deletions) and any
    pertinent data which may be of use in improving this document should
    be addressed to:

USAF Space Division, SD/ALM

P. O. Box 92960

Worldway Postal Center

Los Angeles, CA 90009-2960

By using the self-addressed Standardization Document Improvement
Proposal (DD Form 1426) appearing at the end of this document or by
letter.

The high reliability required of all space and launch vehicles is
achieved by the designs, including the design margins, and by the
manufacturing processes and controls imposed at every level of
fabrication, assembly, and test. The design and design margins should
ensure that the equipment is capable of performing in the operational
environment. The reliability program requirements stated in this
standard have been established to ensure the timely and economical
attainment of system reliability as an integral part of the acquisition
process. The requirements are a composite of those that have been found
to be cost effective on previous space programs.

This standard provides a consistent approach to help achieve, in a cost
effective way, the high reliability required for space and launch
vehicles. For the convenience of the user of this standard, it is
organized similar to MIL-STD-785B, "Reliability Program for Systems and
Equipment Development and Production," although this standard is an
independent document.

This requirements of this standard complement other typical contract
provision, such as the requirement for quality assurance in
MIL-STD-1586, "Quality Program Requirements for Space and launch
Vehicles"; the requirements for a Parts, Materials, and Processes
Control Program in MIL-STD-1546, "Parts, Materials, and Processes
Standardization, Control, and Management program for Spacecraft and
Launch Vehicles"; and the testing requirements in MIL-STD-1540, "Test
requirements for Space Vehicles."

When preparing their proposal, a contractor may include additional tasks
or task modifications. Such added tasks or task modifications should be
clearly identified, include supporting rationale, and be independently
priced for ease of evaluation. Contractor are always encouraged to
report to the contracting officer, for program office review and
consideration, those specific requirements that seem inappropriate, are
believed excessive, or are conflicting with other contract requirements.
However, contractors are reminded that any departure from contractually
imposed requirements can be granted only by the contracting officer.

THIS PAGE INTENTIONALLY LEFT BLANK

CONTENTS

PAGE

1\. SCOPE
.............................................................................
1

1.1 PURPOSE
.........................................................................
1

1.2 APPLICABILITY
............................................................... 1

1.2.1 Application of the Standard
................................................. 1

1.2.2 Application Guidance
........................................................ 1

2\. REFERENCED DOCUMENTS ...............................................
3

2.1 GOVERNMENT DOCUMENTS ..............................................
3

2.2 ORDER OF PRECEDENCE
................................................... 4

3\. DEFINITIONS AND ACRONYMS ...........................................
5

3.1 DEFINITIONS
.................................................................... 5

3.1.1 Acquisition Activity
........................................................... 5

3.1.2 Acquisition Phases
............................................................ 5

3.1.2.1 Conceptual (CONCEPT) Phase
.......................................... 5

3.1.2.2 Demonstration and Validation (VALID) Phase
........................ 5

3.1.2.3 Full-scale engineering Development (FSED) Phase
................... 5

3.1.2.4 Production (PROD) Phase
................................................. 5

3.1.3 Circuit and Item Stress Analysis
............................................. 5

3.1.4 Compensating Features
........................................................ 6

5.  Component
    ......................................................................
    6

6.  Contracting Officer
    ............................................................. 6

7.  Correlated or Sympathetic Failure
    ........................................... 6

8.  Critical Items
    ....................................................................
    6

9.  Failure Effect
    ....................................................................
    7

3.1.9.1 Local Effect
.................................................................. 7

3.1.9.2 Next Higher Level Effect
................................................\... 7

3.1.9.3 End Effect
..................................................................\... 7

10. Failure Mode
    ....................................................................
    8

11. Government Industry Data Exchange Program (GIDEP) .................
    8

12. GIDEP Alert
    ....................................................................
    8

13. Level of Indenture
    ............................................................. 8

14. Mean Mission Duration
    ...................................................... 8

15. Pin-fault Analysis
    ............................................................. 8

16. Single Point Failure (SPF)
    ................................................... 9

17. Sneak Condition
    ............................................................... 9

18. System
    ..........................................................................
    9

19. Tailoring
    ........................................................................
    9

20. Timely
    ........................................................................\...
    10

3.2 ACRONYMS
..................................................................... 10

4\. GENERAL REQUIREMENTS
................................................. 11

4.1 RELIABILITY PROGRAM
.................................................... 11

4.2 QUANTITATIVE REQUIREMENTS ........................................
11

4.3 INTEGRATION WITH OTHER REQUIREMENTS ...................... 11

4.4 INTEGRATED EQUIPMENT
................................................. 11

5\. DETAILED REQUIREMENTS
................................................ 13

SECTION 100. PROGRAM SURVEILLANCE AND CONTROL TASKS ..... 15

TASK

101 RELIABILITY PROGRAM PLAN
............................................ 17

102. MONITORING AND CONTROL OF SUBCONTRACTORS

> AND SUPPLIERS
> ................................................................ 19

103 PROGRAM REVIEWS
........................................................... 21

104 FAILURE REPORTING, ANALYSIS, AND

> CORRECTIVE ACTOIN SYSTEM (FRACAS) .............................. 23

105 FAILURE REVIEW BOARD (FRB)
........................................... 27

SECTION 200. DESIGN AND EVALUATION TASKS ............................ 29

TASK

201 RELIABILTY MODELING
................................................... 31

202 RELIABILITY ALLOCATIONS
............................................... 33

203 RELIABILITY PREDICTIONS
................................................. 35

204. FAILUE MODES, EFFECTS, AND CRITICALITY

> ANALYSIS (FMECA)
> ............................................................ 37

205 DESIGN CONCERN ANALYSIS (DCA) .....................................
47

206 CIRCUIT AND ITEM STRESS ANALYSIS .................................
49

207. PARTS, MATERIALS, AND PROCESSES (PMP)

> PROGRAM
> ........................................................................
> 51

208 RELIABILITY CRITICAL ITEMS
............................................. 53

209 EFFECTS OF FUNCTIONAL TESTING, STORAGE, HANDLKING,

> PACKAGING, TRANSPORTATION, AND MAINTENANCE ........... 55

210 DESIGN FOR RELIABILITY
................................................... 57

SECTION 300. DEVELOPMENT AND PRODUCTION TESTING TASKS ..... 59

TASK

301 ENVIRONMENTAL STRESS SCREENING (ESS) .......................... 61

302. RELIABILITY DEVELOPMENT GROWTH TEST

> (RDGT) PROGRAM
> .............................................................. 63

303 RELIABILITY DEMONSTRATION ..........................................
65

303. PRODUCTION RELIABILITY ACCEPTANCE TEST

> (PRAT) PROGRAM
> ............................................................. 67

APPENDICES

APPENDIX A APPLICATIO GUIDANCE FOR IMPLEMENTATION OF

> MIL-STD-1543 ................................................. 69

APPENDIX B SENAK ANALYSIS FUNCTIONA CLUE LIST ......... 79

APPENDIX C DESIGN CLUE LIST ..........................................
81

APPENDIX D POTENTIAL DESIGN CONCERNS ........................ 83

APPENDIX E APPLICABLE DATA REQURIEMENTS .................. 89

TABLES

Table A-1 APPLICATION MATRIX GUIDE ........................... 70

SECTION 1

SCOPE

1.  PURPOSE

This standard establishes uniform reliability program requirements and
tasks for use during design, development, fabrication, test, and
operation of space and launch vehicles.

2.  APPLICABILITY

1.2.1 [Application of the Standard]{.underline}. This standard, when
appropriately tailored, is applicable to all prime, associate, and
subtier contractors involved in the design, development, fabrication,
test, and initial operation of space and launch vehicles.

1.2.2 [Application Guidance]{.underline}. Application guidance for
tailoring requirements to a particular procurement is contained in
Appendix A. Appendix A and the "DETAILS TO BE SPECIFIED BY THE
ACUISITION ACTIVITY" paragraph at the end of each task contain no
contractor tasking, either directly or implied.

THIS PAGE INTENTIONALLY LEFT BLANK

SECTION 2

REFERENCED DOCUMENTS

1.  [GOVERNMENT DOCUMENTS]{.underline}

Unless otherwise specified, the following specifications, standards, and
handbooks of the issue listed in that issue of the Department of Defense
Index of Specifications and Standards (DoDISS) specified in the
solicitation form a part of this standard to the extent specified
herein.

[Military Standards]{.underline}

> MIL-STD-721 Definitions of Terms for Reliability and Maintainability.

MIL-STD-756 Reliability Modeling and Prediction

MIL-STD-882 System Safety Program Requirements

MIL-STD-1521 Technical Reviews and Audits for Systems,

Equipment and Computer Programs

MIL-STD-1540 Test Requirements for Space Vehicles

MIL-STD-1546 Parts, Materials, and Processes Standardization,

Control, and Management Program for Spacecraft

and Launch Vehicles

MIL-STD-1547 Technical Requirements for Parts, Materials, and

Processes for Space and Launch Vehicles

MIL-STD-1556 Government Industry Data Exchange Program

MIL-STD-1629 Procedures for Performing a Failure

Mode, Effects and Criticality Analysis

MIL-STD-1635 Reliability Growth Management

[Military Handbooks]{.underline}

MIL-HDBK-189 Reliability Growth Management

MIL-HDBK-217 Reliability Prediction of Electronic Equipment

Other Documents

NPRD-3 Nonelectronic Parts Reliability Data,

Reliability Analysis Center RADC

> (Copies of this document may be obtained from Rome Air Development
> Center, Reliability Analysis Center, RDAC/RAC, Griffiss Air Force
> Base, NY, 13441-5200)

(Copies of specifications, standards, and publications required by
contractors in connection with specific procurement functions should be
obtained from the acquisition activity or as directed by the contracting
officer).

2.2 ORDER OF PRECEDENCE

In the event of a conflict between the text of this standard and the
references cited herein, the text of this standard shall take
precedence. However, nothing in this standard shall supersede applicable
laws and regulations unless a specific exemption has been obtained.

SECTION 3

DEFINITIONS AND ACRONYMS

3.1 [DEFINITIONS]{.underline}

Terms are in accordance with the definitions of MIL-STD-721,
MIL-STD-1521, MIL-STD-1556, MIL-STD-1629, and the following definitions:

3.1.1 [Acquisition Activity.]{.underline} The acquisition activity is
the Government office or agency acquiring the equipment, system, or
subsystem to which this standard is being contractually applied.

2.  [Acquisition Phases]{.underline}

3.1.2.1 [Conceptual (CONCEPT) Phase.]{.underline} The conceptual phase
is the initial program acquisition phase that involves the
identification and exploration of alternate solutions or solution
concepts to satisfy a validated operational need.

3.1.2.2 [Demonstration and Validation (VALID) Phase.]{.underline} The
demonstration and validation phase is the program acquisition phase when
selected candidate solutions are refined through extensive study and
analyses; hardware development, if appropriate; test; and evaluations.
Feasibility of one or more candidate solutions to satisfy the
operational need is demonstrated.

3.1.2.3 [Full-scale Engineering Development (FSED) Phase]{.underline}.
The full-scale engineering development phase is the program acquisition
phase when the system and the principal items necessary for its support
are designed, fabricated, tested, and evaluated.

3.1.2.4 [Production (PROD) Phase.]{.underline} The production phase is
the program acquisition phase that starts with production approval and
extends until the last system is delivered and accepted.

3.1.2.5 [Circuit and Item Stress Analysis]{.underline}. Circuit and item
stress analysis relates parts stress to circuit, module, component
(unit), subsystem, and system performance and

reliability, including influence by worst case parameter variations
resulting from environmental effects, radiation effects, aging, input
and output limits, initial operating points, and initial tolerances.

3.1.4 [Compensating Features]{.underline}. Compensating features are
special inspections, tests, controls, instructions, drawing notes, or
other provisions applied to a single point failure mode item to improve
reliability and lessen changes of failures.

3.1.5 [Component]{.underline}. A component is a functional unit that is
viewed as an entity for purposes of analysis, manufacturing,
maintenance, or record keeping. Examples are hydraulic actuators,
valves, batteries, electrical harnesses, and individual electronic boxes
such as transmitters, receivers, or multiplexers. Care should be
exercised when the term component is encountered in other documents
since, in some segments of industry, a piece part is referred to as a
component and the term "unit" is interchanged with the term component.

3.1.6 [Contracting Officer.]{.underline} A contracting officer is a
person with the authority to enter into, administer, or terminate
contracts and make related determinations and findings. The term
includes authorized representatives of the contracting officer acting
within the limits of their authority as delegated by the contracting
officer.

3.1.7 [Correlated or Sympathetic Failure]{.underline}. A correlated or
sympathetic failure is the inability of two (or more) items to perform
their function as the result of some single event, thus possibly
negating redundancy and acting as a single point failure mode (SPFM)
(e.g., loss of a raceway containing redundant power leads or a
pyrotechnic shock causing parallel relays to chatter).

3.1.8 [Critical Items]{.underline}. Critical items are those items which
require special attention because of complexity, application of
state-of-the-art techniques, the impact of potential failure, or
anticipated reliability problems. The following are typical
circumstances which would cause an item to be included on a critical
items list.

a.  Failure of the item would lead directly to severe injury or loss of
    human life.

b.  A failure of the item would seriously affect system operation or
    cause the system to not achieve mission objectives. (See single
    point failure.)

c.  A failure of the item would prevent obtaining data necessary to
    evaluate accomplish of mission objectives.

d.  The item has exhibited an unsatisfactory operating history relative
    to required performance or reliability.

e.  The item has stringent performance requirement in its intended
    application relative to state-of-the-art.

f.  The item does not have sufficient history or similarity to other
    items having demonstrated high reliability to provide confidence in
    its reliability.

g.  State-of-the-art techniques are required to manufacture the item.

h.  The items are stressed in excess of derating criteria.

i.  The item has an operating, shelf-life, or environmental exposure
    limitation which warrants controlled storage or use.

j.  The item is known to require special processing, handling,
    transportation, storage or test precautions.

k.  The item's past history, nature, function, or processing warrants
    total traceability.

3.1.9 [Failure Effect]{.underline}. The failure effect is the
consequence of the failure mode including primary and secondary effects.
Consideration should be given to long term as well as initial effects
and should consider all modes of operation.

3.1.9.1 [Local Effect]{.underline}. The local effect is the
consequence(s) of a failure mode on the operation, function, or status
of the specific item being analyzed.

3.1.9.2 [Next Higher Level Effect]{.underline}. The next higher level
effect is the consequence(s) of a failure mode on the operation,
functions, or status of the items in the next indenture level above the
indenture level under consideration.

3.1.9.3 [End Effect]{.underline}. The end effect is the consequence(s) a
failure mode has on the operation, function, or status of the highest
indenture level.

3.1.10 [Failure Mode]{.underline}. A failure mode is the way or manner
in which an item fails.

3.1.11 [Government Industry Data Exchange Program (GIDEP).]{.underline}
The GIDEP is a program for the collection and exchange of reliability
and other technical information between government agencies and
industry. (See MIL-STD-1556.)

3.1.12 [GIDEP Alert.]{.underline} A GIDEP Alert is a means of
dissemination of information relating to an item deficiency which has
been encountered, usually concerning parts, materials, or processes and
their application.

3.1.13 [Level of Indenture]{.underline}. The level of indenture of an
item is a designation which identifies its relative complexity as an
assembly or function. In a system the first indenture level is the
system. Examples of lower indenture levels could be systems segments
(level 2), prime items (level 3), subsystems (level 4), components
(level 5), Subassemblies or circuit boards (level 6), and parts (level
7).

3.1.14 [Mean Mission Duration.]{.underline} The mean mission duration is
the average time an on-orbit space system is operational before a
mission critical failure occurs. The mean mission duration is equivalent
to mean time to failure for nonrepairable ground systems. The mean
mission duration can be determined using the following formula, which
may be calculated truncated at the end of some specified value or
truncated at the time the contractor estimate wear out or depletion of
expendables will occur.

Picture needs to be added

3.1.15 [Pin-fault Analysis]{.underline}. A pin-fault analysis is a
systematic design evaluation that examines, analyzes, and documents all
potential inadvertent or spurious openings or closures of
current-carrying paths, and determines the effect of each failure (e.g.,
analysis of connector pin-to-pin shorts, pin-to-ground shorts, inductive
or capacitive coupling, printed wiring board traces open or short, and
harness wiring opens or shorts).

3.1.16 Single Point Failure (SPF). A single point failure is any single
hardware failure or software error which results in irreversible
degradation of item mission performance below contractually specified
levels. (The way or manner in which a single point failure of an item
occurs is the single point failure mode (SPFM) of the item).

3.1.17 Sneak Condition. A sneak condition is a condition which causes
the occurrence of an unwanted function or inhibits a desired function
even though all components function properly whether electrical,
mechanical, chemical, or software. Sean conditions include:

a.  Sneak paths, which are current paths that cause an undesirable
    function to occur or inhibit a desired function even though no
    component failure has occurred.

b.  Sneak timing, which is incompatible hardware or logic operational
    sequences which can cause an undesirable function to occur or
    inhibit a desired function.

c.  Sneak indicators, which are circuits which allow improper operation
    or control of sensors or their display devices that can indicate
    false or ambiguous system status.

d.  Sneak labels, which are imprecise instructions or nomenclature o
    controls and operating consoles that lead to operator errors.

3.1.18 [System]{.underline}. A system is a composite of equipment,
skills, and techniques capable of performing or supporting an
operational role, or both. A complete system includes all equipment,
related facilities, material, software, services, and personnel equipped
for its operation and support to the degree that it can be considered a
self-sufficient item in its intended operational environment. The term
system is also used in this standard to refer to the highest level of
requirements and resource grouping applicable to the particular contract
and analysis.

3.1.19 [Tailoring]{.underline}. Tailoring is the process by which the
individual requirements (tasks, sections, paragraphs, words or phrases,
or sentences) of the specifications and standards are evaluated to
determine the extent to which each requirement is most suited for a
specific material acquisition and the modification of these
requirements, where necessary, to ensure that each tailored document
invokes only the minimum needs of the government.

3.1.20 [Timely]{.underline}. As used in this standard, timely
performance of a task, subtask, or effort is performance at a time when
the results will be available to allow management actions to be taken to
preserve system reliability, and to avoid or minimize schedule delays
and cost impacts.

1.  ACRONYMS

> CDR Critical Design Review
>
> CONCEPT Conceptual phase of program acquisition
>
> DCA Design Concern Analysis
>
> ESS Environmental Stress Screening
>
> FMECA Failure Mode Effects and Criticality Analysis
>
> FRACAS Failure Reporting and Corrective Action System
>
> FRB Failure Review Board
>
> FSED Full-scale engineering development phase of
>
> program acquisition
>
> GIDEP Government Industry Data Exchange Program
>
> PDR Preliminary Design Review
>
> PMP Parts, Materials, and Processes
>
> PROD Production phase of program acquisition
>
> RDGT Reliability Development Growth Test
>
> SOW Statement of Work
>
> SPF Single Point Failure
>
> SPFM Single Point Failure Mode
>
> VALID Demonstration and validation phase of program
>
> acquisition

SECTION 4

GENERAL REQUIREMENTS

4.1 [RELIABILITY PROGRAM]{.underline}

The prime, associate, and subtier contractors shall implement and
maintain a reliability program that is planned, scheduled, integrated,
and developed in conjunction with other design, development, and
production functions in accordance with the contractual statement of
work, the requirements of this standard, and the program plan approved
by the acquisition activity. The contractor shall establish and maintain
an internal system of directives, procedures, instructions,
specification, and manuals implement the contractually required
reliability program. The program level of effort shall be adequate to
fulfill the contractual quantitative and qualitative reliability
requirements, and to support economical achievement of overall program
objectives.

2.  [QUANTITATIVE REQUIREMENTS]{.underline}

The minimum acceptable item reliability shall be as stated in the
configuration item specification. Quantitative reliability requirements
for all major items shall be stated in the appropriate section of each
item specification. The quantitative values not defined by the
contracting officer, and those to be allocated from the system
requirements, shall be established by the contractor though trade-off
analyses prior to the Preliminary Design Review (PDR), and shall be
updated for the Critical Design Review (CDR) and subsequent formal
reviews.

3.  INTEGRATION WITH OTHER REQUIREMENTS

The reliability program effort shall be closely coordinated with the
design engineering and test programs as well as configuration management
and integrated logistic support. The reliability program shall also be
closely integrated with the related disciplines of quality assurance;
maintainability; human engineering; system safety; software development;
and parts, materials, and processes control to preclude duplication of
effort and produce integrated cost-effective results.

4.  INTEGRATED EQUIPMENT

Where items such as government furnished equipment or directed source
hardware are to be integrated into the end item, know or estimated
reliability predictions and analyses for

These items shall be used in the contractor's reliability predictions
and other analyses. Reliability related problems introduced by inclusion
of such items shall be identified to the contracting officer.

SECTION 5

DETAILED REQUIREMENTS

The detailed requirements are contained in the following task
descriptions.

THIS PAGE INTENTIONALLY LEFT BLANK

SECTION 100

PROGRAM SURVEILLANCE AND CONTROL TASKS

THIS PAGE INTENTIONALLY LEFT BLANK

TASK 101

RELIABILITY PROGRAM PLAN

101.1 [PURPOSE]{.underline}

The purpose of Task 101 is to require the contractor to develop a
reliability program plan which identifies and integrates all program
tasks required to accomplish contractual reliability requirements.

2.  [TASK DESCRIPTION]{.underline}

101.2.1 A reliability program plan shall be prepared and shall include
the following:

a.  A description of how the reliability program will be conducted to
    meet the tailored requirements of this standard as specified in the
    contract, and to ensure that quantitative reliability requirements
    are met.

b.  A detailed description of how each reliability task, including
    contractor added or modified tasks, is to be performed or complied
    with, including estimated time phasing. The purpose and expected
    results of each task and the planned methods for monitoring,
    assessing, reporting, and taking appropriate action regarding the
    status, accomplishments, and problems shall be described.

c.  A description of the contractor's organizational element assigned
    responsibility and authority for implementing the reliability
    program tasks. Key personnel managing the reliability program shall
    be identified by name and title.

d.  The identification of analyses or data bases required by the
    reliability program which may satisfy or be satisfied by an analysis
    or data base from a related design or specialty engineering
    function. The plan shall identify common users, earliest
    requirement, and variations in content and format for each user.
    Common requirements of the functional areas listed in paragraph
    101.2.1.e as a minimum shall be considered. As an example, a
    computer-aided engineering data base would be used to obtain
    application data for use in performing a reliability prediction.

e.  Interfaces between the reliability program and related programs or
    functions, including as a minimum:

```{=html}
<!-- -->
```
(1) Quality assurance

(2) Human engineering

(3) System safety

(4) Part, material, and process controls

(5) Maintainability

(6) Logistic support analysis

(7) Design engineering

(8) System engineering

(9) Software development

(10) Test engineering

(11) Manufacturing

```{=html}
<!-- -->
```
f.  A procedure for maintaining a list of items having the greatest
    impact on reliability, including known reliability problems. For
    each item on the list, the contractor shall also list as assessment
    of their impact on meeting contractual reliability requirements and
    any actions being taken to ensure that the items do not preclude
    meeting contract requirements.

g.  Description of design guidelines and parts derating criteria, and
    the method for their dissemination to design personnel.

h.  The reliability program plan shall describe the contractor's methods
    of controlling subtier contractor reliability. The reliability
    program plan shall include a list of subcontracts which contain
    quantitative reliability requirements or require a forma reliability
    program.

    2.  DETAILS TO BE SPECIFIED BY THE ACUISITION ACTIVITY

(Reference paragraph 1.2.2)

101.3.1 Tailoring of the required reliability tasks.

103.3.2 If the reliability program plan is to become part of a Product
Assurance or System Effectiveness Plan.

103.3.3 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E. Applicable data items for this task are listed in
Appendix E. Normally the reliability program plan and initial list of
reliability impact items (paragraph 101.2.1.f) are reuired with the
contractor's proposal.

TASK 102

MONITORING AND CONTROL OF SUBCONTRACTORS AND SUPPLIERS

102.1 [PURPOSE]{.underline}

The purpose of Task 102 is to require the prime contractor to perform
appropriate surveillance and management control of subcontractor and
suppliers reliability programs so that program progress can be monitored
and timely management action taken when warranted.

102.2 [TASK DESCRIPTION]{.underline}

102.2.1 The contractor shall ensure that subcontracted items obtained
from first and all lower tier suppliers meet reliability requirement
compatible with required system reliability. Intra-company work orders
shall be considered subcontractors. Compliance with this task does not
relieve the prime contractor of responsibility for the quality and
reliability of all material delivered as a result of this contract.

102.2.2 The contractor's and subtier contractor's requirements
documentation shall reflect the applicable requirements of this
standard. The contractor's documentation shall be subject to review and
disapproval by the contracting officer. All subcontracts requiring
elements of this document to control the subcontracted item's
reliability shall include provision for on site review and evaluation of
the suppliers reliability efforts by the prime contractor and by the
acquisition activity.

102.2.3 The reliability program plan shall describe the contractor's
methods of controlling subtier contractor reliability. The program plan
shall include a list of all subcontract which contain quantitative
reliability requirements or require a formal reliability program. This
list shall be maintained current and available for review at the
contractor's facility.

4.  The contractor shall:

```{=html}
<!-- -->
```
a.  Ensure that subcontracted items are defined by specification,
    drawing, and technical documentation including numerical reliability
    requirements consistent with system reliability.

b.  Verify the reliability of subcontracted hardware/software designs
    during subcontractor design reviews.

c.  Require and ensure that subcontractor reliability tasks are
    performed in a timely manner.

d.  Review subcontractor's reliability prediction and analysis for
    accuracy, proper approach, and ability to meet required reliability
    requirements.

e.  Ensure that subcontractor's have a vigorous closed loop failure
    reporting and corrective action system (FRACAS) to eliminate causes
    of unreliability.

f.  Integrate the subcontractors FRACAS data with the prime contractor's
    FRACAS.

g.  Ensure that sufficient testing is performed on subcontracted items
    to support the system reliability demonstration.

    4.  The contractor shall have a system for identifying problems
        which may prevent subcontractor from meeting reliability
        requirements. The contractor shall notify the contracting
        officer when such problems exist and indicate actions being
        taken to resolve the problems.

102.3 [DETAILS TO BE SPECIFICED BY THE ACQUISITION
ACTIVITY:]{.underline}

102.3.1 Note that Task 104 is a prerequisite for specifying tasks
102.2.4.e and 102.2.4.f.

TASK 103

PROGRAM REVIEWS

103.1 [PURPOSE]{.underline}

The purpose of Task 103 is to establish a requirement for the contractor
to conduct reliability program reviews at specified points in time to
ensure that the reliability program is proceeding in accordance with
contractual milestones and that the system, subsystem, equipment, and
component quantitative reliability requirements will be achieved in
delivered equipment.

103.2 [TASK DESCRIPTION]{.underline}

103.2.1 The reliability program shall be planned and scheduled to permit
the contractor and acquisition activity to periodically review program
status. Formal review and assessment of progress in meeting contract
reliability requirements shall be conducted at major program reviews
specified by contract.

103.2.2 The contractor's reliability personnel shall participate in
contractor and subcontractor design reviews, PDRs, CDRs, and in internal
design reviews, such as pre-PDRs, post-PDRs, and pre CDRs of an item.
Results of these design reviews shall be recorded, and shall be
available to the acquisition activity for detailed examination at the
contractor's or subcontractor's facilities during the term of the
contract. Contractor and subcontractor PDRs, CDRs, internal design
reviews, and design audits should include:

a.  Status of all applicable reliability tasks at the time of review,
    including progress on the task and results to date.

b.  A review of current and potential reliability problems, potential
    impact on the program, and plans for their resolution.

c.  The reliability content of specifications, and the ability of the
    current design to comply with reliability requirements.

103.2.3 The contractor shall develop and apply a procedure to document
and follow-up on design review decisions, action items, and agreements
to ensure that the design reflects the results of design reviews.

103.2.4 The contractor shall notify the contracting officer of design
reviews at least ten working days prior to the review. The acquisition
activity reserves the right to have representatives attend program
reviews as an active participant and to attend internal and
subcontractor reviews as an observer.

3.  [DETAILS TO BE SPECIFICED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

\(R\) 103.3.1 The contract should specify major program reviews
indicated in paragraph 103.2.1. This is usually done through the use of
MI-STD-1521 as a compliance document in the SOW. When MIL-STD-1521 is
contractually specified, the requirements of this task may be fulfilled
by appropriate tailoring of MIL-STD-1521.

103.3.2 Any data item to be delivered as a result of the task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 104

FAILURE REPORTING, ANALYSIS, AND CORRECTIVE ACTION SYSTEM

(FRACAS)

104.1 [PURPOSE]{.underline}

The purpose of Task 104 is to establish a closed loop failure reporting
system. This failure reporting system shall include procedures for
recording and analysis of each failure to determine its cause,
determination of actions necessary to correct deficiencies in the failed
hardware, determination of actions necessary to eliminate the cause of
the failure, verification that the corrective action, as implemented, is
adequate to correct the problem, and to ensure that all actions are
properly documented.

2.  [TASK DESCRIPTION]{.underline}

104.2.1 The contractor shall maintain and shall require subcontractors
to maintain a closed loop FRACAS as required in this task description.
Data from the subcontractor's FRACAS shall be integrated into the
contractor's FRACAS. Procedures developed to implement this task shall
be integrated and coordinated with procedures developed for handling
nonconforming items and corrective action under the quality assurance
program requirements of the contract.

104.2.2 On qualification and production hardware and software, failures
and anomalies shall be reported at all levels of test and inspection
after first application of power at lowest level of assembly. Each
failure shall require investigation for cause (failure analysis) and
corrective action. An unscheduled adjustment, other than a calibration
made during maintenance actions, shall be considered a failure for the
purposes of the FRACAS. Piece part failure analyses shall be
incorporated into the FRACAS. Failures of equipment undergoing
reliability development growth testing (RDGT) shall be included in the
FRACAS. Functional failures caused by software or hardware to software
interfaces shall be included in the FRACAS and be subject to the same
failure analysis and corrective action processes.

104.2.3 Failure analysis shall be conducted to the lowest level of
indenture necessary to identify the failure cause and mechanism. The
analysis shall begin with an on-the-spot review by reliability or
quality engineering supervision and the responsible test engineer this
review shall be conducted prior to removal of the failed hardware from
the test setup, unless removal of the hardware is required for safety.
The failure

analysis shall include evaluation of potential overstress of other parts
or components due to the failure. Failure analysis shall be planned to
minimize the probability of improperly sequenced actions that could
obscure the basic failure cause.

104.2.4 In order to allow acquisition activity participation in the
failure analysis, the contractor shall notify the contracting officer
within one working day of system level, mission or schedule critical
failures.

104.2.5 When the cause of the failure has been determined, corrective
actions shall be developed which correct the suspect item, eliminate the
underlying failure cause, and prevent its recurrence. Corrective actions
shall be coordinated with design engineering, quality assurance,
manufacturing and with other activities, as appropriate. Corrective
actions shall be implemented in a timely manner. Adequacy of corrective
actions performed shall be verified through appropriate testing
including as a minimum, rerunning the test in which the failure
originally occurred. The failure report shall not be closed until
corrective actions are implemented, their adequacy verified, and
approval of the acquisition activity is obtained. All failures shall be
resolved prior to flight.

104.2.6 All hardware with the same configuration as the failed item
shall be considered suspect and suitably controlled. Serialized suspect
flight hardware shall be addressed by serial number in corrective action
statements.

104.2.7 The contractor's FRACAS shall contain a suspense audit system
including assignment of suspense dates for failure analysis, corrective
actions and follow-up when suspense dates are not met. Delinquencies
shall be reported to the program management level, and addressed at
program management reviews.

104.2.8 The contractor's FRACAS shall have provision for a periodic
analysis and summarization of FRACAS data to identify trends, recurring
failures and open and closed failure reports that could significantly
affect reliability performance, schedule or cost for presentation to
program management. The contractor shall use appropriate statistical
techniques for summarizing, analyzing, and presenting the data. The
analysis shall detect trends in failure causes as well as hardware and
software configurations in all levels of assembly, test, and use.

104.2.9 The contractor's FRACAS records shall include the following
information as a minimum:

a.  Date of the failure.

b.  Identification of the failed item including part number,
    nomenclature, and serial number.

c.  Description of the test conditions at the time of failure including
    identification of test procedure and revision, test paragraph,
    environmental condition, and previous environments the item was
    subjected to, if pertinent.

d.  Symptoms of the item under test at the time of failure.

e.  Results of attempts to repeat failure, when applicable.

f.  Signature of the person initiating the failure report.

g.  Signature of the person verifying the failure.

h.  Steps taken to determine the cause of the failure and their results.

i.  Identification of the part or p\[arts that failed.

j.  Inherent cause of the failure.

k.  A statement regarding the effects of the failure and failure
    analysis on the failed item under test.

l.  If redundant, an assessment of the impact of the failure on the
    operation of the system using the redundant path.

m.  Identification and location of flight hardware with the same
    configuration as the failed item under test. This hardware is
    considered suspect.

n.  A description of corrective actions taken with the failed item under
    test and other suspect hardware, scheduled accomplishment and
    appropriate concurrences.

o.  A description of corrective actions taken to eliminate the failure
    cause and prevent its recurrence, scheduled accomplishment, and
    appropriate concurrences.

p.  Actions taken to verify corrective actions including the extent of
    retest, the results, and the signature of the individual verifying
    the corrective action.

104.2.10 The contractor shall participate in the Government Industry
data Exchange Program (GIDEP) to the extent necessary to generate ALERTs
and receive ALERTs from the GIDEP Operations Center. The contractor
shall screen ALERTed parts against his parts list. The contractor shall
notify the contracting officer of the usage of any suspect part,
describe its location and usage in the system, the effects of its
failure on the system, and actions taken to mitigate these effects or
reduce the probability of failure. The contractor shall be able to
identify and locate suspect parts incorporated into hardware.
Investigations of ALERTs shall be addressed at parts, materials, and
processes control board (PMPCB) meetings.

104.2.11 To implement the FRACAS during testing of research and advanced
development nonflight and prequalification hardware, logs shall be
maintained of significant events, discrepancies and failures. These logs
shall represent a complete failure and discrepancy history of each item.
These logs shall be periodically reviewed and hardware and design
corrective actions taken to eliminate failure causes.

2.  [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

104.3.1 The requirement for the proposal to include an estimate of the
number of failures expected by program phase and the basis for the
estimate for use during negotiations should be included in the request
for proposal.

104.3.2 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 105

FAILURE REVIEW BOARD (FRB)

105.1 [PURPOSE]{.underline}

The purpose of Task 104 is to establish a failure review board to review
failure trends, significant failures, corrective action status, and to
ensure that adequate follow-up and corrective actions are taken in a
timely manner ad are properly recorded.

2.  [TASK DESCRIPTION]{.underline}

105.2.1 An FRB shall be established and maintained to review failure
trends, significant failures, delinquent corrective actions, and ensure
adequate and timely corrective actions. The FRB shall meet regularly,
normally weekly, after occurrence of the first reportable failure. All
failure occurrence information shall be available to the FRB. All
failures shall require closeout approval by the FRB. The FRB shall
monitor the status of corrective action implementation. Minutes of FRB
activity shall be recorded and kept on file for detailed examination by
the acquisition activity during the term of the contract.

105.2.2 Contractor FRB members shall include representatives from system
engineering, design engineering, reliability, parts engineering,
materials and processes engineering, system safety, manufacturing, and
quality assurance as a minimum. The acquisition activity reserves the
right to appoint a representative to the FRB with right of disapproval
of FRB decisions. The chairman of the FRB shall have sufficient
authority to resolve conflicts between members and to ensure prompt and
effective implementation of corrective action.

3.  This task shall be coordinated with procedures for handling of
    nonconforming material and corrective action required by the quality
    assurance provisions of the contract to ensure there is no
    duplication of effort.

```{=html}
<!-- -->
```
2.  [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

    1.  Task 104 is a prerequisite for specifying this task.

    2.  Specify the organizational level of the FRB chairman, when
        appropriate.

THIS PAGE INTENTIONALLY LEFT BLANK

SECTION 200

DESIGN AND EVALUATION TASKS

THIS PAGE INTENTIONALLY LEFT BLANK

TASK 201

RELIABILITY MODELING

201.1 [PURPOSE]{.underline}

The purpose of Task 201 is to require development of a reliability model
to be used for making numerical apportionments and reliability
predictions from the system through component levels.

2.  [TASK DESCRIPTION]{.underline}

201.2.1 The contractor shall develop and maintain a reliability
mathematical model based on system, subsystem, and equipment functions,
for the system and for each configured item required to perform the
mission functions. Models shall be developed using the methods defined
in MIL-STD-756 or unique methods appropriate for contractor equipment. A
reliability block diagram shall be developed and maintained for the
system. The model shall be made to the component level, as a minimum,
and shall include probability of success with associated failure rates.
The reliability block diagram shall be traceable to and cross-referenced
to the functional block diagram, schematics and drawings. The physical
location of redundancy switching circuits shall be clearly identified in
the model. Nomenclature of items used in reliability block diagram shall
be consistent with that used in functional block diagrams, drawings,
schematics, weight statements, power budgets, and specifications. The
reliability mathematical model shall be updated with information
resulting from FMECAs, reliability test, other relevant tests, changes
in item configuration, mission parameters, and operational constraints.
Inputs and outputs of the reliability mathematical model shall be
compatible with the input and output requirements of the system,
subsystem, and component level analysis models. The model shall include
software, and software to hardware interfaces, as necessary to define
mission reliability.

201.2.2 The model outputs shall be expressed in terms compatible with
contractual reliability requirements and other reliability terms as
specified.

201.2.3 When specified in the SOW, models shall be developed for
alternate and degraded operational modes and to support logistic support
analysis.

3.  [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2).

201.3.1 Tasks 202 and 203 are normally specified in conjunction with
this task.

2.  Identification of numerical reliability requirements, mission
    parameters, and operational constraints.

3.  Level of indenture to which model should be developed if other than
    component level.

4.  Identification of alternate model requirements (reference paragraph
    201.2).

5.  Any data item to be delivered as a result of this task should be
    specified on a DD Form 1423. Applicable data items for this task are
    listed in Appendix E.

TASK 202

RELIABILITY ALLOCATIONS

202.1 [PURPOSE]{.underline}

The purpose of Task 201 is to ensure that quantitative system
reliability requirements are allocated or apportioned to lower levels of
indenture.

2.  [TASK DESCRIPTION]{.underline}

202.2.1 Quantitative contractual reliability requirements shall be
allocated to the component level or lower if necessary to determine a
reliability requirement for a configured item specification and shall be
used to establish baseline requirements for

202.2.2 All allocated reliability values established by the contractor
and included in contract item specifications shall be consistent with
the reliability model and any changes there to are subject to
acquisition activity review.

3.  The reliability allocations shall include all software and firmware.

202.3 [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

202.3.1 Task 201 is a prerequisite for specifying this task.

202.3.2 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

THIS PAGE INTENTIONALLY LEFT BLANK

TASK 203

RELIABILITY PREDICTIONS

203.1 [PURPOSE]{.underline}

The purpose of Task 203 is to estimate the reliability of the system and
to determine if contractual reliability requirements can be achieved
with the proposed design.

2.  [TASK DESCRIPTION]{.underline}

203.2.1 The contractor shall perform reliability predictions for all
items using methods approved by the contracting officer. Predictions
shall account for and differentiate between each mode of item operation
as defined in the item specification and the reliability program plan.
The probability that the system can perform the required mission shall
be determined as a function of time for the period from initial use
through design life or wearout. This prediction shall include alternate
missions and modes of operation. The resulting data shall be presented
in tabular and graphical formats. The contractor shall perform these
predictions using the associated reliability mathematical model and
reliability block diagram. The contractor is encouraged to use models
and failure rates unique to the equipment, subject to approval of the
contracting officer.

203.2.2 The reliability prediction shall include predictions for
software and firmware reliability as related to system reliability.

203.2.3 When a Failure Mode, Effects, and Criticality Analysis (FMECA)
is required, results of the FMECA shall be reflected in the predictions.
Items excluded from the prediction as mission nonessential shall have
substantiating FMECAs which verify that the item failure cannot cause
mission failure. Prior to such exclusions from the predictions, an
assessment shall be made relating functioning of the item to system
performance and approval shall be obtained from the contracting officer.
Exclusions shall be clearly identified in all analyses and predictions.
Usage of operational duty cycles of less than 100 percent shall require
approval of the contracting officer and be clearly identified in all
analyses and prediction.

203.2.4 Predictions for electronic equipment shall be made using the
methods and failure rates contained in MIL-HDBK-217, or alternatives
approved by the contracting officer. Predictions for mechanical,
electrical, and electromechanical

equipment shall be made using NPRD-3, contractor data, or other
alternative data, subject to approval of the contracting officer. A
probabilistic approach to design and reliability predication shall be
considered for mechanical items for which stress and strength
relationships can be estimated. The failure rate adjustment factor for
standby operation and storage shall be submitted with substantiation to
the contracting officer for approval. A standby failure rate adjustment
factor of not less than 0.5 shall be used for failure rates of one or
less failures per 10^8^ hours.

203.2.5 The Mean Mission Duration for the system shall be predicted
truncated at the end of the expected mission life and truncated at the
end of useful life (e.g., at the point in time that the contractor
estimates wearout or depletion of expendables will occur).

203.2.6 For spacecraft, as part of the reliability prediction and
end-of-life prediction shall be made. The end of life prediction shall
be made in a probabilistic sense considering such items as depletion of
expendables, solar cell, thermal protection, and storage battery
degradation.

3.  [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

203.3.1 Task 201 is a prerequisite for specifying this task.

203.3.2 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

203.3.3 Any items, other than the system, for which the mean mission
duration should be calculated.

4.  The failure rate adjustment factor for standby operation.

5.  Failure rates or predictions for government furnished equipment.

6.  Ide3ntification of item life profile and mission profile.

TASK 204

FAILURE MODES, EFFECT, AND CRITICALITY ANALYSIS

(FMECA)

204.1 [PURPOSE]{.underline}

204.1.1 The purpose of Task 204 is to determine and document all
possible failure modes and their effects on mission success through a
systematic analysis of the design. The analysis is intended to identify
needed reliability improvements in a timely manner and to foster
interchange of design information with other program activities such as
system safety, instrumentation, test, and other reliability analyses.

204.1.2 In addition to the above, the FMECA shall be used for the
following specific purposes:

a.  To ensure that an organized and exhaustive effort has been made to
    identify all failure modes, that their mission effects have been
    determined, and that either corrective or compensating action ha
    been taken or that the risk to program success associated with no
    further action is acceptable and approved by the contracting
    officer.

b.  To identify single point failure modes (SPFM) and define their
    effects.

c.  To identify those areas of the design where redundancy for critical
    functions should be implemented.

d.  To identify compensating features for those single point failure
    modes whose elimination is impractical.

e.  As an aid in identifying functions, including redundancy, which are
    not or cannot be tested.

f.  As a ranking technique for concentrating program attention on the
    most serious failure modes.

g.  As a basis for establishing and updating a critical items list and
    critical item control plans.

h.  As an input to reliability modeling, predictions, and assessments.

i.  As an iterative design tool to achieve the most reliable design
    consistent with program objectives.

j.  As a design evaluation tool for use in selecting the optimum design
    from competing design candidates and as inputs to design trade-offs.

k.  As a diagnostic tool during mission planning, testing, and
    operations.

l.  To assure that the effects of failures and their criticality on
    personnel, equipment, and facilities are analyzed and documented in
    accordance with the definitions and criteria for the system safety
    hazard analyses of MIL-STD-882.

m.  As a criterion for test planning, manufacturing and quality control,
    instrumentation points, preflight checkout, and related program
    activities.

n.  As an aid in determining flight and ground operational constraints
    and in defining failure indications and recovery actions for orbital
    operation and contingency plan documents.

o.  As an input to logistics support and maintainability.
    Maintainability, human engineering design, and operational criteria
    shall be developed and implemented as a result of the FMECA.

p.  To identify problem areas to be avoided in manufacturing work
    instructions; in selecting materials, processes, and equipment; and
    in inspection, test, and quality control planning for manufacturing.

    2.  TASK DESCRIPTION

204.2.1 The FMECA shall be conducted in accordance with this task and
MIL-STD-1629. Tasks 101, 102, and 105 of MIL-STD-1629 shall be
performed. The major thrust of these analyses shall be identification
and elimination of, or compensation for, failure modes to improve
reliability. Emphasis shall be placed on eliminating SPFM by design, or
where elimination is not feasible, on reducing SPFM likelihood or impact
by incorporating compensating features. All corrective

actions, procedural changes, test, quality control measure, or other
compensating features described in the FMECA shall be incorporated into
the methods which the contractor establishes for critical item control
as required by this standard.

204.2.2 The system under analysis shall include all contractual items,
equipment supplied by subcontractor and associate contractors, and
integration activities required by the contract such as those related to
Government furnished equipment. The FMECA shall include electrical,
electronic, mechanical, thermal, electromechanical, hydraulic,
pneumatic, optical, structural, propulsion, and ordnance mission
hardware.

204.2.3 In addition to hardware failure modes analyses, the FMECA shall
include consideration of potential system failure due to software, test
equipment and procedures, human error, operational procedures, and loss
or change in characteristics of inputs.

204.2.4 [Mission Phases]{.underline}. The FMECA shall be conducted for
all phases of a mission including prelaunch (launch preparation),
launch, transfer orbit, orbit injection, acquisition, normal orbital
operation, reacquisition, orbit changes, and reentry, as these phases
are defined in the applicable system requirement document. Even though
the contractor's hardware may function during only a limited portion of
the mission, the effect upon interfacing hardware during these phases
and the effect upon subsequent operation of the contractor's hardware
shall be determined. Emphasis shall be placed on critical portions of
the mission where reliability estimates provide little informational
such as the launch portion of a satellite mission.

204.2.5 [System Operating Modes]{.underline}. The FMECA shall be
conducted for all modes of system operation including normal operating
modes, contingency modes, dormant modes, back-up autonomous,
nonautonomous modes, ground-controlled modes, and transition between
modes as these are defined in applicable system requirements documents.

204.2.6 [Failure Modes Analyzed]{.underline}. In addition to the failure
conditions cited in Task 101 of MIL-STD-1629, failure modes identified
in the following shall be incorporated in the FMECA.

204.2.6.1 Redundancy Effects. The effect upon the system resulting from
redundancy management shall be included. Interfaces and isolation
techniques for redundant elements shall be analyzed to ensure that the
desired redundancy is not negated due to failure of any interfaces or
isolation techniques

(especially wiring and other circuit paths). Redundant elements which
are not independently testable shall be regarded as potential single
point failure modes. Typical factors include the following:

a.  Malfunction signaling, sensing, logic, and switching

b.  Effect of subsystem selections

c.  Ability to check out redundant items

d.  Failure detectability in operation

e.  Effect of correlated or sympathetic failures

f.  Effect of inadvertent switching

g.  Effect of early or late time-out or time-in events

204.2.6.2 [Related Activities]{.underline}. The FMECA shall include
failure modes detected by related analyses, investigations, tests,
reviews, and other studies. Failure modes identified during the
following activities shall be integrated with the FMECA as specified
below:

a.  The circuit and item stress analysis, Task 206, if applicable.

b.  Dynamic analyses, analyses of structures, and mechanisms that are
    conducted in the performance of the contract.

c.  Test failures, inspection discrepancies, GIDEP alerts, information
    on operation of similar equipment.

d.  System safety analyses.

204.2.7 [Failure Detection]{.underline}. Emphasis shall be placed on
those conditions where timely action is required, in particular, those
failures which, if left alone, would progress to an uncorrectable state
and cause mission failure.

204.2.7.1 [Flight Detection]{.underline}. The FMECA shall verify that
instrumentation, including telemetry, is provided for purposes of
in-flight failure detection. The FMECA shall verify that the
instrumentation is adequate to support redundancy management, and
provides for isolation of failure to significant functional elements.
When the same telemetry indicator is used to represent more than one
potential problem condition, the FMECA shall

define the effect of misinterpreting the indicator and correcting for
the wrong condition. For vehicles where command and control impossible,
time limits from detection of a problem to implementation of corrective
action shall be defined.

204.2.7.2 [Ground Test and Checkout.]{.underline} The FMECA shall verify
that system functions are testable to ensure satisfactory status prior
to commitment to flight.

204.2.7.3 [Safety Related Failures]{.underline}. The FMECA shall verify
that telemetry and test instrumentation is adequate to detect safety
related failure conditions.

204.2.8 [Types of FMECAs]{.underline}. A number of different types of
FMECAs are listed in the following subparagraphs. These FMECAs shall be
developed in conjunction with each other, so that the output of one
FMECA can be the input to another.

204.2.8.1 [Functional FMECA]{.underline}. The contractor shall perform a
functional FMECA, including both time-dependent and time-independent
failure modes. The functional FMECA normally is used when hardware items
cannot be uniquely identified, or when system complexity requires
analysis from the initial indenture level downward through succeeding
indenture levels. All system functions, including electrical,
electronic, mechanical, structural, chemical, ordnance, command,
telemetry, and software shall be identified in addition to the
redundancy contained in each. The contractor shall develop a functional
block diagram of the system or applicable portions, traceable to the
corresponding equipment. The contractor shall, by search, analysis, or
simulation, determine the effects on system functions of single failures
in accordance with the requirements of this standard. The analysis shall
include the response of the system to o failures where the ability to
restore full system function or preserve partial system function by the
use of redundancy or by other action may depend upon the elapsed time
since the failure. Examples of these kinds of failures include those
which lead to control instability, cyclic thermal or mechanical stress,
or leakage of propellants. The functional FMECA shall make provision for
different levels of analysis based on the mission phase and function
criticality for which the function is being analyzed.

204.2.8.2 [Hardware FMECA]{.underline}. AS the design progresses, the
contractor shall perform a more detailed FMECA, based on the physical
designs of the system, subsystems, and components being analyzed. The
analysis shall be performed down to the piece part level in the priority
established by the criticality classification of the mission functions.
Piece part failure modes shall be analyzed when necessary to identify a
component

failure mode, its cause, or its effect. A component FMECA shall be
performed on each component regardless of whether or not the component
or its function is redundant in the system. For redundant components,
the FMECA shall be insufficient depth to identify failure modes that can
influence redundancy implementation.

204.2.8.3 [Interface FMECA]{.underline}. The contractor shall identify
and analyze all of the interfaces at all levels of hardware. The
contractor shall develop a functional, hardware related, block diagram
of the system, or applicable portions, traceable to the corresponding
equipment. Failures in any one subsystem component or interconnecting
circuit which cause thermal, electrical, or mechanical damage or
degradation to any other subsystem or component, or within the
component, shall be identified. Any interfaces between the space vehicle
and payloads shall be included. The analysis shall include software
interfaces that can have an impact on mission success. Pin-fault
analysis shall be conducted as part of this FMECA.

204.2.8.4 [Product Design-manufacturing FMECA]{.underline}. The
contractor shall analyze the manufacturing documentation, such as
circuit board layouts, wire routings, connector keying, and hardware
implementation of the design to determine if new failure modes have been
introduced as a result of production implementation of the design. The
FMECA shall be performed initially from design drawings and shall be
updated by reference to current manufacturing work instructions.

204.2.8.5 [Large Scale Integration]{.underline}. For the purposes of
this standard, Very Large Scale Integrated Circuits (VLSIC), Very High
Speed Integrated Circuits (VHSIC), Custom Large Scale Integration
(CLSI), and Hybrid Semiconductor Devices shall be considered to be
components. Hardware FMECA (paragraph 204.2.8.2) and product design
--manufacturing FMECA (paragraph 204.2.8.4) shall be performed on these
devices. Early emphasis, at or prior to PDR, shall be placed on hybrids,
on devices newly designed or modified for the system, and on devices
with no history of successful use in similar applications.

204.2.8.6 [Sneak Analysis]{.underline}. As part of the Functional FMECA
(paragraph 204.2.8.1) and Interface FMECA (paragraph 204.2.8.3) the
contractor shall apply the functional clue list (Appendix B.) to
identify sneak conditions. The analysis shall employ a systematic
approach to ensure that all system functions are performed when and only
when required and that any sneak conditions are identified. As part of
the hardware FMECA the contractor shall apply the design clue list
(Appendix C) to identify design related sneak conditions.

204.2.9 [Timeliness.]{.underline} The FEMCA shall be performed in a
timely manner, that is, at such time in the flow from concept to end
system use that the FMECA may effectively fulfill the purposes stated in
paragraph 204.1.2. The analysis shall be scheduled and completed
concurrently with the design effort so that the design reflect the
results of the analysis. The FMECA shall be maintained current with the
design and other program activities.

204.2.10 [FMECA Update and Review]{.underline}. Change to the design,
fabrication, packaging, procedural, or other activities shall require an
update of the affected portion of the FMECA and Critical Items List.
This update shall be accomplished within 30 days of the change. The
FMECA shall be updated whenever testing reveals a failure mode that was
not included in the FMECA analysis.

204.2.11 [Mission Readiness Review]{.underline}. After CDR, the FMECA
shall be reviewed for each space vehicle and launch vehicle. These FMECA
reviews shall be conducted in conjunction with each applicable hardware
technical audit and mission readiness review. As a result of each FMECA
review, the FMECA shall be updated as necessary to include an analysis
of all changes to the design, test results to date, and the as-built
configuration of each spacecraft and launch vehicle. All new single
point failures shall be listed and reviewed to ensure each is eliminated
or the mission effects reduced in accordance with paragraphs 204.2.12.1
of this standard. The effectiveness of each single point failure
correction shall also be reviewed and the residual risk reported.

204.2.12 [FMECA Data]{.underline}

204.2.12.1 [Single Point Failure Modes (SPFM)]{.underline}. The
contractor shall identify all SPFMs, classify each by severity of
mission impact, and present the results at all design reviews, technical
audits, and mission readiness reviews. Mission critical SPFMs shall be
eliminated from the design or their mission effects reduced to the
lowest practical level. The contractor shall develop and maintain a
current listing of all SPFMs characterized by mission impact,
probability of occurrence, and practicality of correction. The
contractor shall recommend compensating features in the form of design,
manufacturing, or other corrective actions to eliminate or reduce the
mission effects or probability of occurrence of each SPFM. Justification
shall be given for each single point failure that is not detectable
during ground test and checkout. This record shall be available for
inspection by the Government on request.

204.2.12.2 [Configuration Identification]{.underline}. The contractor
shall identify FMECA entries and items directly and unambiguously to the
specific item configuration (such as specific drawing number revision or
engineering change proposal) covered by the analysis. Traceability shall
be maintained between all elements of the FMECA, e.g., from component to
subsystem, to system level FMECAs.

204.2.12.3 [Analysis Data]{.underline}. In addition to information
required by Task 101 and 102 of MIL-STD-1629, the FMECA shall include
the following data:

a.  Redundancy management conditions as noted in paragraph 204.2.6.1.

b.  Symptoms and warnings prior to failure occurrence shall be included.

c.  Critical items shall be identified. The Critical Items List shall
    also be maintained as a separate document.

d.  Identification of failure modes impacting safety.

e.  As estimate of the probability of occurrence of each failure mode.
    For other than uncorrected SPFMs (paragraph 204.2.12.1) and critical
    items, probability estimates may be by range groupings indicating
    relative probabilities if the actual estimates are not available.

f.  Identification of failure modes for which ground checkout, launch
    preparation checkout or flight instrumentation is inadequate for
    timely detection.

204.2.12.4 [Supporting Data]{.underline}. In addition to the analysis
results of paragraph 204.2.12.3, the FMECA shall include the following
supporting information:

a.  A system, system segments, subsystem, and component description
    including a functional block diagram. The functional block diagram
    should show all items comprising a system, system segment, subsystem
    or component, the series and redundant relationships among the
    items, the interconnections between the items, the interface
    circuitry, the monitoring points, the switching capability, each of
    the item's inputs and outputs, and inputs to the system as a whole.
    A separate functional block diagram may be required. The

> description shall include a comprehensive narrative description of the
> operation of each item for each system operating mode with any unusual
> functions fully described.

b.  A cross-reference to data base information used in support of the
    FMECA, with significant data extracted as needed for completeness
    and clarity.

c.  Any other required graphical data such as the following shall be
    included as required to support the FMECA:

```{=html}
<!-- -->
```
1.  Functional flow diagrams

2.  Cross section drawings

3.  Cutaway views

4.  Worst case analysis data

5.  Fault trees

6.  Connector and wiring lists

7.  Schematic diagrams

8.  Design layouts

9.  Printed circuit board layouts

204.2.13 [Audit and Review]{.underline}. The contractor shall develop
techniques for determining the adequacy of their FMECA, subject to the
approval of the contracting officer. These techniques shall include a
contractor audit and review jointly with the Government (or its
designated representative). The review shall include an overall
evaluation, a detailed review of selected critical design
characteristics, associated critical manufacturing process, and a
sampling review of other areas. If the review process discloses
undetected SPFM, the FMECA procedures and their implementation shall be
evaluated and a corrective action plan submitted to the contracting
officer. Corrective action may include use of modified methods or
different analysts as required to ensure adequacy of the FMECA.

2.  [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

204.3.1 Tasks 201, 203, and 208 are generally specified in conjunction
with this task.

204.3.2 The approach to be used in performing the criticality analysis
(Task 102, MIL-STD-1629) should be specified. Refer to para. 50.8

204.3.3 Schedule of Delivery of Contract Data Requirements List (CDRL)
Items. In order to facilitate timely and effective use of the FMECA ad
to foster early agreement on FMECA planned

approach and content, it is recommend that the submittal of Contract
data Requirements List deliverables be required in accordance with the
following typical schedule:

204.3.3.1 With proposal: FMECA Plan (Task 105, MIL-STD-1629), system
function FMECA (paragraph 204.2.8.1). Preliminary single point failure
mode list (paragraph 204.2.12.1).

204.3.3.2 Prior to System PDR: System functional FMECA update (paragraph
204.2.8.1) and Interface FMECA (paragraph 204.2.8.3).

204.3.3.3 Prior to component PDR, if a component PDR is conducted
(otherwise at a comparable time in the component design schedule):
Component FMECA (paragraph 204.2.8.2) and update of Interface FMECA
(paragraph 204.2.8.3).

204.3.3.4 Prior to first release of product design drawings or
equivalent information: product design-manufacturing FMECA (paragraph
204.2.8.4).

204.3.3.5 Update. In addition to the initial submittals above, updates
should be submitted prior to each subsequent major activity (e.g.,
Critical Design Review, Physical Configuration Audit). In some cases it
may also be desirable to require addition submittals, either on a
periodic basis, or in conjunction with other milestone.

204.3.4 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 205

DESIGN CONCERN ANALYSIS (DCA)

205.1 [PURPOSE]{.underline}

The purpose of Task 205 is to identify design weaknesses which can
manifest themselves as failures or degraded performance during the
useful life of the system.

2.  TASK DESCRIPTION

205.2.1 The contractor shall perform an independent analysis of the
design to identify design weaknesses such as inadequate redundancy
provision, timing inconsistencies, out-of-specification operating modes,
improperly applied components, and unnecessary components. The
contractor shall develop a design concern list appropriate to the
equipment he is designing. Appendix D contains examples of potential
design concerns. The contractor shall systematically apply the design
concern list to identify design weaknesses. The DCA shall be scheduled
and completed concurrently with the design effort so that the design
reflects the analysis conclusions and recommendations. The results of
the DCA shall be documented including equipment analyzed, design
weaknesses identified, and their disposition. The results of the DCA
shall be available for acquisition activity review and new failure modes
shall be incorporated into the FMEA, if applicable.

205.2.2 The contractor's procedure for conducting DCA and a sample
worksheet shall be submitted to the contracting officer prior to PDR for
approval. The procedure shall identify who, by discipline, will perform
the analysis and what parts and components are to be analyzed.

205.2.3 The ultimate intent is for DCA to be conducted as part of a
reliability and maintainability computer aided design (RAMCAD) system.
However, specification of this task shall not be construed as a
requirement for the contractor to have a reliability and maintainability
computer aided design (RAMCAD) system. When applicable the computerized
DCA technique shall use the most current computer aided design data, be
modular, provide computer compatible results in a project standard
format, and be integrated with other computerized techniques in a manner
that avoids duplication of effort.

3.  [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

205.3.1 Items or criteria for selection of items to be subjected to DCA.

205.3.2 Submittal of DCA procedure and DCA worksheet in accordance with
paragraph 205.2.2.

205.3.3 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 206

CIRCUIT AND ITEM STRESS ANALYSIS

206.1 [PURPOSE]{.underline}

The purpose of Task 206 is to examine the effects of part and circuit
parameter tolerances and parasitic parameters over the range of
specified operating life and conditions and to ensure compliance to
approved parts derating criteria.

2.  [TASK DESCRIPTION]{.underline}

206.2.1 During the design and development phase, the contractor shall
perform sensitivity analyses which relate the parts operation and stress
to circuits, modules, components, subsystems and system performance as
they are influenced by:

a.  Maximum input and output variation.

b.  Maximum line voltage variations and line transients.

c.  Maximum part parameter variation.

d.  Maximum performance demands and variations.

e.  Maximum and minimum environmental conditions

f.  Fail safe provisions.

g.  Redundancy provisions.

h.  Radiation effects, as applicable.

i.  Parameter drift due to aging.

j.  Transients due to turn-on, turn-off and state changes.

k.  Fatigue due to cyclical loading.

206.2.2 A worst case analysis shall be performed to verify that, given
reasonable combinations of parts tolerance buildup, the circuitry being
analyzed will function within specification requirements.

206.2.3 A circuit stress analysis shall be performed to ensure that
approved derating requirements have been complied with.

206.2.4 These analyses shall be scheduled and performed as an integral
part of the design effort and analysis results shall be presented at
design reviews. These analyses shall be performed in conjunction with
the contractor's testing to verify design margins. The contractor shall
correlate the results of these analyses with the FMECA, when Task 204 is
contractually imposed. Results of these analyses shall be available for
acquisition activity review prior to item CDR.

2.  DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY

(Reference paragraph 1.2.2)

206.3.1 Identification of the environmental envelope within which the
equipment is to operate.

206.3.2 Specification of or criteria for selection of parts and circuits
to be analyzed.

206.3.3 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 207

PARTS, MATERIALS, AND PROCESSES (PMP) PROGRAM

207.1 [PURPOSE]{.underline}

The PMP program for spacecraft and launch vehicles should be planned and
accomplished in conjunction with the Reliability Program. It is usually
specified as a separate item in the SOW using MIL-STD-1546,
appropriately tailored. This Task 207 does not task the contractor.

2.  [TASK DESCRIPTION]{.underline}

> Not Applicable.

3.  [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

> Not Applicable.

THIS PAGE INTENTIONALLY LEFT BLANK

TASK 208

RELIABILITY CRITICAL ITEMS

208.1 [PURPOSE]{.underline}

1.  The purpose of Task 208 is to identify and control those items which
    require special attention because of complexity, application of
    state-of-the-art techniques, anticipated reliability problems, or
    the impact of potential failure on safety, readiness, and mission
    success.

208.2 [TASK DESCRIPTION]{.underline}

208.2.1 An item shall be considered a critical item if it contains one
or more single point failure modes. Additional critical items shall be
identified based on the contractor's experience and using the criteria
in paragraph 3.7 as guidance.

208.2.2 The contractor shall establish and maintain an effective method
for identification, control and test of critical items from initial
design through final acceptance. The method(s) the contractor uses for
critical item control shall be described in the contractor's formal
policies and procedures to ensure that all affected personnel such as
design, purchasing, manufacturing, inspection, and test personnel are
aware of the essential and critical nature of such items. Periodic
reviews at PDR, CDR, Functional Configuration Audit (FCA), and Physical
configuration Audit (PCA), as a minimum, shall be used by the contractor
and the acquisition activity to determine if additions or deletions to
the critical item list and control plan(s) and procedures are warranted,
and to assess the effective ness of the critical item controls and test.
Each critical item control method and plan to be used shall be subject
to on-going review and evaluation by the acquisition activity.

208.2.3 The critical item list shall include items having critically
limited useful life such as maximum total operating time or operating
cycles. The maximum allowable operating time or cycles of operation
shall be clearly defined along with the elements of data and
computational methods used in their derivation. The contractor shall
maintain a record for each such item that contains its total operating
time or number of equivalent operating cycles, starting with and
including its initial functional testing, whether at the contractor's or
supplier's facility. The operating time records shall become part of the
acceptance documentation.

208.2.4 The contractor shall establish and maintain a current list of
critical items. The list shall contain all critical items which have not
been dispositioned or removed by the acquisition activity. The critical
items list shall contain the following FMECA information, when Task 204
is contractually required.

a.  The identification of the item under analysis, the same information
    described in paragraph 4.5.2 of MIL-STD-1629, and a statement as to
    whether or not it is a single point failure mode.

b.  Citation of the pages or entry identifications of the FMECA that
    described the failure modes.

c.  Statements identifying compensating features included in the design
    (e.g., extra safety margins), control methods (e.g., overstress
    testing, process controls, special checkout procedures), or other
    practices incorporated to minimize the occurrence of failures
    associated with critical items.

    1.  DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY

(Reference paragraph 1.2.2)

Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 209

EFFECTS OF FUNCTIONAL TESTING, STORAGE, HANDLING,

PACKAGING, TRANSPORTATION, AND MAINTENANCE

209.1 [PURPOSE]{.underline}

The purpose of Task 209 is to determine the effect of storage, handling,
packaging, transportation, maintenance, and repeated exposure to
functional testing on hardware reliability.

209.2 TASK DESCRIPTION

209.2.1 The contractor shall establish, maintain and implement
procedures to determine by test and analysis, or estimation, the effects
of storage, shelf-life, packaging, transportation, handling, maintenance
and repeated exposure to testing on the design and reliability of a
product. The results of this analysis shall be used to support design
trade-offs, definition of allowable test exposures, retest after storage
decisions, special handling, transportation, packaging, or storage
requirements and refurbishment plans.

209.3 DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY

(Reference paragraph 1.2.2)

209.3.1 The SOW should identify functional testing, storage, handling,
packaging, transportation, and maintenance profiles. Applicable data
items for this task are listed in Appendix E.

THIS PAGE INTENTIONALLY LEFT BLANK

TASK 210

DESIGN FOR RELIABILITY

210.1 [PURPOSE]{.underline}

The purpose of Task 210 is to ensure use of techniques which have proven
successful in achieving a reliable design.

210.2 TASK DESCRIPTION

1.  The contractor shall give preference to hardware, software, and
    hardware designs that have performed successfully in the intended
    actual mission environment. Unproven designs shall be validated by
    analysis and test as part of the design process. The approved
    derating criteria, including radiation effects when applicable,
    shall be established for use by designers and deviations to the
    criteria shall require joint approval of the contractor's system
    engineering, parts engineering, and reliability managers. The
    contractor's electronic parts derating criteria for design shall be
    consistent with part derating policy in MIL-STD-1547. The contractor
    shall use part standardization, type and quantity minimization,
    stress derating, redundancy, fault isolation, single point failure
    minimization, and stress-strength analysis in his design These
    program peculiar criteria shall be developed for and used by the
    designers.

210.2.2 The contractor shall ensure optimum application of all
redundancy techniques (active, passive, and graceful degradation).
Single point failure modes shall not be permitted for mission critical
components, except as provided in Task 204, paragraph 204.2.12.1, when
applicable. Design for redundancy shall utilize independent paths of
operation or communication and provide for a high degree of assurance of
effective successful operation during intermittent failure modes.

210.2.3 The contractor shall perform a reliability analysis of the
system as an integral part of the overall system engineering analysis.
Criteria for the analysis shall include operational and support
concepts, requirements, and environmental conditions. The results of
these reliability analyses shall be used during design, development, and
test to evaluate the achievement of the reliability design requirements.
The contractor shall not compromise reliability or reliability related
criteria such as maintainability, quality assurance, electromagnetic
compatibility, electromagnetic interference, safety, or parts
requirements in an attempt to exceed contractually specified performance
criteria.

210.2.4 Whenever design trade-offs are performed, or engineering change
proposals are generated, the contractor shall define the effects of the
proposed change(s) on the reliability of the entire system. The details
of the trade-offs involving system reliability and the results of any
design change on reliability shall be evaluated, recorded, and reflected
in the reliability analysis.

210.3 [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2).

Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

SECTION 300

DEVELOPMENT AND PRODUCTION TESTING TASKS

THIS PAGE INTENTIONALLY LEFT BLANK

TASK 301

ENVIRONMENTAL STRESS SCREENING (ESS)

310.1 [PURPOSE]{.underline}

Test requirements for parts, components, and systems used in spacecraft
and launch vehicles are specified in MIL-STD-1546, MIL-STD-1547, and
MIL-STD-1540. Some of the requirements in these documents perform an
environmental stress screening function. These standards appropriately
tailored are included in a separate portion of the contract. The purpose
of this task is to define reliability program functions related to
environmental stress screening.

301.2 [TASK DESCRIPTION]{.underline}

301.2.1 Environmental stress screening, including burn-in, shall be
conducted on selected components and subassemblies to eliminate early
and potential failures due to latent part defects, workmanship defects,
undetected design defects, and undetected failure modes.

301.2.2 During development, subassemblies and components shall be
identified and applicable ESS procedures shall be formulated. Key
factors in the selection of items and ESS levels include development
tests, past history on similar equipment, item technology, fabrication
techniques, and FMECA results, when performed.

301.2.3 ESS shall be designed to stimulate relevant failures by
stressing the item through application of environmental and operational
stresses. When ESS planned levels exceed qualification test levels, an
analysis shall be performed and justification provided prior to
implementation or levels adjusted accordingly.

301.2.4 Upon approval of the proposed ESS procedures, a detailed ESS
plan shall be prepared. The ESS plan shall include the following:

a.  Identification of the items to be subjected to ESS.

b.  Description of environmental stress types, levels, profiles, and
    exposure times to be applied.

c.  Identification of item performance and stress parameters to be
    monitored during ESS.

d.  Proposed ESS duration, including failures free time and maximum
    exposure time.

e.  Criteria for removal of an item from ESS.

    3.  DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY

(Reference paragraph 1.2.2)

Data items to be delivered as a result of this task should be specified
on the DD Form 1423. Applicable data items for this task are listed in
Appendix E.

TASK 302

RELIABILITY DEVELOPMENT GROWTH TEST (RDGT) PROGRAM

302.1 [PURPOSE]{.underline}

Designs for long life and high reliability space systems require
sufficient design margins to ensure long life. The limited number of
systems produced and the relatively short development period preclude
sufficient testing to identify marginal designs and hidden failure
modes. The purpose of Task 302 is to conduct prequalification testing to
provide a basis for resolving a majority of reliability problems early
in the development phase, and to ensure adequate design margins
appropriate to long-life, high reliability space systems.

2.  [TASK DESCRIPTION]{.underline}

302.2.1 Reliability development growth tests shall be conducted for the
purpose of enhancing system reliability through the identification,
analysis, and correction of failure modes, and the verification of
corrective action effectiveness. Guidance for conducting RDGT is
contained in MIL-STD-1635 and MIL-HDBK-189.

302.2.2 Reliability growth tests shall include application of
environmental, power, and performance stresses sufficient to identify
design weaknesses and to induce failure or demonstrate design margins.
This generally requires stresses beyond operational design
specifications. Test items shall include normal interface connections
between assemblies and components, to ensure new failure modes are not
introduced in system operation.

302.2.3 Reliability growth testing shall be integrated with the
development testing specified in MIL-STD-1540. Items selected for RDGT
shall include assemblies and components for which the design is new or
operational history is inadequate to satisfy mission requirements.

4.  An RDGT plan shall be prepared and shall include the following,
    subject to contracting officer approval prior to initiation of
    testing:

```{=html}
<!-- -->
```
a.  Test objectives and requirements, including growth model, growth
    rate, initial and final reliability values, and their rationale.

b.  Identification of the equipment to be tested and number of test
    items.

c.  Test conditions including environmental, operations, and performance
    profiles, as applicable.

d.  Test schedules and cross reference to development tests.

e.  Procedures for corrective action.

f.  Data recording and collection requirements.

302.3 [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

302.3.1 Failure reporting in accordance with Task 104, FRACAS, should be
specified.

302.3.2 Recommended candidates for RDGT.

302.3.3 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 303

RELIABILITY DEMONSTRATION

303.1 [PURPOSE]{.underline}

The purpose of Task 303 is to demonstrate that the quantitative
reliability requirements have been met. Although this task is included
in the Development and Production Testing Section, it should be
recognized that the reliability demonstration for spacecraft and launch
vehicles is performed analytically using the reliability prediction,
FMECA, item failure reports, and program test data.

2.  [TASK DESCRIPTION]{.underline}

303.2.1 The contractor shall implement and maintain a reliability test
and demonstration program that is planned, integrated, and developed
with the system and equipment test program, such as development testing,
quality assurance testing, performance, flight testing, item testing,
and maintainability demonstration, to avoid duplicate testing. This
program shall include the requirements of this standard and receive
acquisition activity approval prior to implementation. The program shall
include all reliability testing and demonstration to be performed for
the program. Test shall be designed to make maximum use of reliability
data from all sources. Unless otherwise specified by the contract, the
contractor shall analytically demonstrate the achievement of minimum
acceptable hardware reliability requirements as part of qualification.
The analytical methods, assumptions and piece part failure rates to be
used shall have specific approval of the contracting officer. The
contractor shall use the results of program tests, Failure Modes,
Effects and Criticality Analyses (FMECAs), when required, and item
failure reports to qualitatively evaluate the demonstration results as
part of the assessment of the item predictions.

303.2.2 The contractor shall identify to the contracting officer items
which are candidates for reliability evaluation, reliability development
growth testing or life tests. As a minimum, these shall include items
that have limited documented history of previous usage to support the
life requirements of the program. Reliability evaluation or life tests
shall be performed as directed by the contracting officer. The
contractor's reliability evaluation or life test plans shall be included
in the Program Test Plan and be detailed with sample sizes, test
duration, confidence level, test conditions, and accept-reject criteria
as a minimum. The FMECA, when required

shall be used as an aid in the design of the test plans and procedures.
Test results shall be used to ascertain the item's capability to comply
with the program reliability requirements.

303.2.3 The results of contractor's functional and environmental testing
of items during the design and development phases shall be analyzed to
estimate achieved reliability, to provide confidence in the predicted
reliability, and to provide feed back to support design changes that
impact reliability. A log book shall be maintained for each item
identified on the program equipment listing to record its operating
times during assembly, test, and operation. The development testing
program shall be used to confirm the following factors, down to the
piece part level: adequacy of item selection, safety margins, parameter
drift with time, failure modes, and establishment of human performance
operation and maintenance variability criteria.

302.2.4 The contractor shall make use of statistical planning and
analysis in the test program. This may include application of such
methods as design of experiments, analysis of variance, and other
methods applicable to design, development, production, and operational
phases. Consideration should be given to the use of accelerated test
techniques suitable to the equipment under test, provided the test
results can be extrapolated to estimate mission reliability.

303.3 [DETAILS TO BE SPECIFIED BY THE ACQUISITION ACTIVITY]{.underline}

(Reference paragraph 1.2.2)

303.3.1 Quantitative reliability requirements.

303.3.2 Any data item to be delivered as a result of this task should be
specified on a DD Form 1423. Applicable data items for this task are
listed in Appendix E.

TASK 304

PRODUCTION RELIABILITY ACCEPTANCE TEST (PRAT) PROGRAM

This task generally is not applicable to spacecraft and launch vehicle
contracts.

Custodians Preparing Activity

Air Force -- 19 Air Force -- 19

(Project No. RELI-F009)

Document 1646b/Arch 1256b

THIS PAGE INTENTIONALLY LEFT BLANK

APPENDIX A

APPLICATION GUIDANCE FOR IMPLEMENTATION OF MIL-STD-1543

This appendix is not a mandatory part of this standard.

10. GENERAL

10.1 [SCOPE.]{.underline} This appendix provides guidance for the
selection of reliability tasks as they apply to various acquisition
phases and is not to be construed as mandatory.

10.2 [PURPOSE]{.underline}. This appendix is to be used to tailor the
standard in the most cost-effective manner that meets established
program objectives. Additional tailoring guidance and descriptions of
the task and their function in a complete reliability program can be
found in Appendix A to MIL-STD-785, "Reliability Program for Systems and
Equipment Development and Production." In addition, Table A-1 is an
application matrix guide for the program acquisition phases. The matrix
should be used for general guidance since the tailoring constraints
(paragraph 40.2) can seriously affect applicability of each task.

20. REFERENCED DOCUMENTS

> MIL-STD-781 Reliability Testing for Development,
>
> Qualification, & Production
>
> MIL-STD-785 Reliability Program for Systems and
>
> Equipment Development and Production

30. DEFINITIONS.

> Not applicable.

40. GENERAL APPLICATION REQUIREMENTS

40.1 [ACQUISITION ACTIVITY RESPONSIBILITY]{.underline}. The acquisition
activity needs to ensure that tailored reliability requirements are
applied in contracts, statements of work, or requests for proposals, as
applicable (reference paragraph 40.2).

40.2 [TAILORING OF TASK DESCRIPTIONS AND DATA ITEMS]{.underline}.
Applicable tasks are to be selected and task descriptions tailored as
required by governing regulations and as necessary to meet program
objectives based on equipment complexity, criticality, quantity,
category, program type, magnitude and

TABLE A-1. Application Matrix Guide

![](media/image1.wmf)

Funding, acquisition phase, and life cycle cost. The cost of imposing
each requirement this standard should be evaluated against the benefits
that could be realized. The "DETAILS SPECIFIED BY THE ACQUISITION
ACTIVITY" paragraph under each task description is intended for listing
the specific details, additions, modifications, deletion, or options to
the requirements of the task that should be considered by the
acquisition activity when tailoring the task description to fit the
program needs. Items annotated by an "(R )" are essential and shall be
provided to the contractor for proposer implementation of the task. All
items should be reviewed and tailored, as applicable, to ensure that the
preparation instructions in the statement of work.

3.  [REALIABILITY PROGRAM OBJECTIVES]{.underline}:

```{=html}
<!-- -->
```
a.  [CONCEPT phase:]{.underline} Specific values of reliability
    characteristics in operational terms are derived from generic
    reliability needs of the mission area. Quantitative reliability
    objectives are refined based on system level trade studies.

b.  [VALID phase:]{.underline} To require identification of critical
    parameters that impact reliability either by test or by analysis. A
    formal reliability program is required only if the system or
    equipment criticality or total acquisition cost suggest its need.
    Usually, the updating of reliability requirements within the design
    plan is sufficient. Updating can include test monitoring, failure
    analysis, and corrective action feedback.

c.  [FSED phase]{.underline}: A fully developed program does not
    necessarily contain all tasks of this standard but it should be
    capable of being independently evaluated to determine the
    effectiveness of the task in providing design assurance.

d.  [PROD phase:]{.underline} To maintain design integrity and to ensure
    that implementation of the design in production does not detract
    from its inherent reliability. Design changes and critical or
    special processes require evaluation and monitoring. The results of
    failure analysis, process trends and field feedback should be
    analyzed during the production phase and design and manufacturing
    corrections implemented as necessary.

```{=html}
<!-- -->
```
50. TASK OBJECTIVES

    1.  TASK 101, RELIABILITY PROGRAM PLAN

```{=html}
<!-- -->
```
a.  [CONCEPT phase:]{.underline} Generally not applicable unless
    hardware development, such as experiments, are involved.

b.  [VALID phase:]{.underline} To provide assurance that all
    requirements are planned and scheduled. Depending on the criticality
    and category of equipment, the program plan could be developed as a
    separate entity or with other test and design planning.

c.  [FSED phase]{.underline}: To establish a clearly identified
    reliability program including the necessary organizational authority
    to influence the achievement of reliability program milestones. A
    fully developed and controlled program, which includes report of
    status and problem areas to all levels of management, should be
    administered by the reliability organization. It is highly desirable
    that a single reliability contact point be established for all
    acquisition activity interfaces.

d.  [PROD phase]{.underline}: To continue functions of the reliability
    organization to the extent necessary to ensure that engineering
    changes or production processes do not degrade design reliability.

502.2 [TASK 102, MONITOR AND CONTROL OF SUBCONTRACTORS AND
SUPPLIER]{.underline}. This task is intended to minimize the risk of not
achieving the required system reliability due to poor reliability of
subcontracted supplies. The task requires contractor inclusion of
allocated requirements in subcontracts and surveillance of subcontractor
reliability activities. It should be noted that even if this task is not
specified the prime contractor is responsible for the reliability of
subcontracted supplies.

50.3 [TASK 103, PROGRAM REVIEWS.]{.underline} Program reviews are not
tailored by program phase but should be planned and scheduled as
appropriate for the acquisition activity to review its status and
results achieved. For major complex programs, separate Reliability
Program Reviews should be required. When MIL-STD-1521 is specified as a
compliance document in the SOW, appropriate tailoring of that document
may preclude the need for this task.

4.  [TASK 104, DISCREPANCY AND FAILURE RECORDING, ANALYSIS AND
    CORRECTIVE ACTION AND TASK 105, FAILURE REVIEW BOARD.]{.underline}

```{=html}
<!-- -->
```
a.  [CONCEPT phase:]{.underline} Not applicable unless hardware, such as
    an experiment, is to be fabricated as part of the contract.

b.  [VALID phase:]{.underline} To impose a formal failure reporting and
    corrective action system (FRACAS) to varying degrees depending on
    the expected volume of failures for the particular program and the
    criticality of major system components. If a reliability development
    test is imposed, the greatest benefit can be derived from failures
    encountered during that testing program through the use of a FRACAS.

c.  [FSED phase:]{.underline} To obtain maximum benefit from correction
    of failures encountered during any formal qualification nor
    acceptance testing. Contractor procedures may be used prior to
    formal qualification or acceptance testing.

d.  [PROD phase:]{.underline} To obtain maximum benefit from correction
    of failures encountered during any manufacturing test or acceptance
    tests. Provision should be made by the acquisition activity to
    ensure that the user provides adequate failure information to assist
    the corrective action process.

    4.  [TASK 201, RELIABILITY MODELING]{.underline}

```{=html}
<!-- -->
```
a.  [CONCEPT and VALID phases:]{.underline} Applicable at the system
    level to facilitate reliability analyses and trade studies.

b.  [FSED phase]{.underline}: The math model is necessary to facilitate
    reliability allocations, prediction, and FMECA. The initial math
    model may be to the subsystem, level, with the model progressing to
    the component and part level as the design evolves and becomes firm.

c.  [PROD phase: Normally]{.underline}, only major design changes would
    require a revision to the R model.

    4.  [TASK 202, RELIABILITY ALLOCATIONS]{.underline}

```{=html}
<!-- -->
```
a.  [CONCEPT and VALID phases]{.underline}: Applicable at the system
    level to facilitate reliability analyses and trade studies.

b.  [FSED phase:]{.underline} The reliability allocation should be
    performed early in the FSED phase to serve as a baseline requirement
    for designers and subcontractors.

c.  [PROD phase:]{.underline} Not applicable.

    4.  [TASK 203, RELIABILITY PREDICTION]{.underline}

```{=html}
<!-- -->
```
a.  [CONCEPT phase]{.underline}: Limited to functional levels of design.
    Details are not normally defined at this stage of development.

b.  [VALID phase:]{.underline} Fully applicable.

c.  [FSED phase:]{.underline} Fully applicable.

d.  [PROD phase:]{.underline} Reliability Prediction is restricted to
    significant Engineering Change Proposals.

50.8 [TASK 204, FAILURE MODES EFFECT AND CRITICALITY
ANALYSIS.]{.underline} The FMECA is potentially one of the most
beneficial and productive tasks I a well structured reliability program.
Since individual failure modes are listed and evaluated in an orderly
organized fashion, the FMECA serves to verify design integrity, identify
and quantify sources of undesirable failure modes, and document the
reliability risks. The FMECA is an essential design evaluation
procedures which should not be limited to the phase traditionally
thought of as the design phase (FSED). When the criticality analysis
(Task 102, MIL-STD-1629) is required, the quantitative or qualitative
method should be specified. Whenever possible, the quantitative method
using probability of occurrence rather than criticality number should be
specified. The specific FMECA tasks should be selected and applied for
greatest cost effectiveness in accordance with the type and phase of the
program. Provisions (section, paragraphs or sentences) not required for
the specific application should be excluded.

a.  [CONCEPT phase]{.underline}: FMECA is performed to functional levels
    of design.

b.  [VALID phase]{.underline}: FMECA is performed to functional levels
    of design and systems determined to be critical.

c.  [FSED phase]{.underline}: Fully applicable, but tailored to be
    compatible with program requirements.

d.  [PROD phase:]{.underline} FMECA update may be necessary for
    significant Engineering Change Proposals and based on test results
    or on-orbit performance.

    9.  [TASK 205, DESIGN CONCERN ANALYSIS (DCA)]{.underline}

```{=html}
<!-- -->
```
a.  [CONCEPT and VALID phases]{.underline}: Not applicable.

b.  [FSED phase]{.underline}: DCA should be scheduled and completed
    concurrently with the design effort.

c.  [PROD phase:]{.underline} DCA is restricted to update due to
    extensive engineering changes or if system deficiencies have been
    identified by other means.

50.10 [TASK 206, CIRCUIT AND ITEM STRESS ANALYSIS]{.underline}

a.  CONCEPT and VALID phases: Applicable when hardware, such as
    experiments, are developed under the contract.

b.  FSED phase: Fully applicable.

c.  PROD phase: Applicable only to Engineering Change Proposals.

50.11 [TASK 207, PARTS, MATERIALS AND PROCESSES (PMP)
PROGRAM]{.underline}

a.  [CONCEPT phase]{.underline}: May be fully applicable when hardware,
    such as an experiment, is required to be developed.

b.  [VALID phase]{.underline}: To Continue involvement in component
    application trade-offs and development of design application
    criteria. Planning should be developed for full implementation
    during full scale development.

c.  [FSED phase]{.underline}: Fully applicable.

d.  [PROD phase]{.underline}: Fully applicable.

    12. [TASK 208, RELIABILITY CRITICAL ITEMS]{.underline}

```{=html}
<!-- -->
```
a.  [CONCEPT phase]{.underline}: Restricted to systems element
    consideration.

b.  [VALID phase]{.underline}: To establish a control mechanism within
    design planning where critical items are identified.

c.  [FSED phase]{.underline}: Fully applicable.

d.  [PROD phase]{.underline}: Continue critical item controls defined in
    the critical item control plan.

    12. [TASK 209, EFFECTS OF FUNCTION TESTING, STORAGE, HANDLING,
        PACKAGING, TRANSPORTATION, AND MAINTENANCE]{.underline}

```{=html}
<!-- -->
```
a.  [CONCEPT and VALID phase]{.underline}: Applicable if hardware is
    developed.

b.  [FSED phase]{.underline}: Fully applicable. Requirements and
    controls should be developed and implemented. Particular emphasis
    should be placed on this task when space vehicle storage is
    anticipated.

c.  [PROD phase]{.underline}: Implement controls and procedures
    established in the development phase.

    12. [TASK 210, DESIGN FOR RELIABILITY]{.underline}

> 50.14.1 [Design Techniques]{.underline}

a.  [CONCEPT phase]{.underline}: To be considered to the extent
    necessary to support preliminary design and trade studies.

b.  [VALID phase]{.underline}: To emphasize those techniques which
    involve basic design characteristics that could have a significant
    impact on the reliability of the final design. Because of the
    fluidity of the design in this phase, caution is advised against
    prematurely requiring application of techniques which may have to be
    repeatedly revised during the design evolution. Tasks which fall
    into this category include but are not limited to such techniques as
    worst-case analysis and parameter variance analysis.

c.  [FSED phase]{.underline}: The final baseline design destined for
    production should be subjected to reliability design analysis
    through application of appropriate design techniques. Therefore, in
    this phase, maximum application of such techniques is suggested,
    consistent with a cost-benefit evaluation of each technique and the
    potential impact on system performance, reliability, producibility,
    and ultimate life-cycle cost.

d.  [PROD phase]{.underline}: To be restricted to only those cases where
    design modifications are implemented or where necessary to support
    engineering failure investigations.

50.14.2 Reliability Analysis. The depth of this task increases as the
program progresses through development. This task is applicable to
CONCEPT, VALID, and FSED phases; it has limited application to the PROD
phase except as appropriate when changes in function occur.

50.15 [TASK 301, ENVIRONMENTAL STRESS SCREENING (ESS).]{.underline}

a.  CONCEPT and VALID phases: Not applicable.

b.  FSED phase: With the limited quantity of test items, it is difficult
    to identify all design and workmanship defects prior to production
    of flight hardware. ESS should be applied to programs and hardware
    on a selective basis, particularly where lower level equipment
    failures can cause significant rework and retest at higher levels.
    During this phase equipment and test levels should be selected and
    defined for ESS to screen out workmanship, design, and part
    failures.

c.  PROD phase: The approved test defined during FSED should be
    conducted. Criteria should be established for removing items from
    ESS or reducing test levels as design and production matures.

50.16 [TASK 302, RELIABILITY DEVELOPMENT GROWTH TESTING]{.underline}.

a.  [CONCEPT phase]{.underline}: Not applicable.

b.  [VALID phase]{.underline}: Consider a test, analyze, and fix
    approach to reliability testing to uncover weaknesses in design
    approaches that were not previously detected by engineering analysis
    or testing. This testing consists of a sequence of tests, analyzing
    all failures, incorporating corrective action, and retesting to
    provide a basis for program decisions.

c.  [FSED phase]{.underline}: A dedicated test, analyze, and fix
    approach to reliability testing should be imposed during this phase
    of acquisition cycle. This test should be designed, utilizing
    dedicated samples and sufficient test time, to uncover design
    deficiencies not detected during previous testing or analyses.

d.  [PROD phase]{.underline}: Selectively applicable when design changes
    require reliability growth in the hardware.

50.17 [TASK 303, RELIABILITY DEMONSTRATION]{.underline}

a.  [CONCEPT phase]{.underline}: Not applicable.

b.  [VALID phase]{.underline}: Not applicable.

c.  [FSED phase]{.underline}: To provide confidence that the equipment
    design meets or exceeds program objectives. The test components used
    for this demonstration-analysis shall be the best available
    representation of the production configuration. The test-analysis
    also serves to confirm the effective ness of corrective actions and
    provide a statistical assessment of program status for the
    production decision process.

d.  [PROD phase]{.underline}: To provide confidence by sampling and
    combining the equipment test to ensure that that equipment
    reliability continues to meet or exceed program objectives and was
    to degraded to an unacceptable level by the production process.

50.18 [TASK 304, PRODUCTION RELIABILITY ACCEPTANCE TEST (PRAT)
PROGRAM]{.underline}. Generally not applicable. If appropriate for a
specific program Task 304 of MIL-STD-785, "Reliability Program for
Systems and Equipment Development and Production," may be used, or
MIL-STD-781, "Reliability Testing for Development, Qualification, &
Production," may be applied directly.

APPENDIX B

SNEAK ANALYSIS FUNCTIONAL CLUE LIST

This appendix is not a mandatory part of this standard.

1.  Do functions perform as intended?

2.  Are all functions and ground compatible with the power sources?

3.  Is power available when required to activate a function?

4.  Are connected grounds compatible?

5.  Are connected power sources from different power buses, i.e., is
    there a potential power-to-power tie?

6.  Can any function be activated inadvertently or at incorrect times?

7.  Are there undesired effects when a current or energy path is
    unintentionally opened or closed?

8.  Can any combination of functions be activated by an unintended
    current or energy path?

THIS PAGE INTENTIONALLY LEFT BLANK

APPENDIX C

DESIGN CLUE LIST

This appendix is not a mandatory part of this standard.

[SNEAK PATHS]{.underline}

1.  Are signals apparently routed to unintended places: Is there an
    apparent reversal of polarity or phase between signals?

2.  Can an operational amplifier be driven into saturation
    unintentionally?

3.  Are totem pole outputs of digital devices connected together?

4.  Do circuits containing symmetry have any asymmetric elements or
    paths?

5.  Are grounds mixed in the same circuit?

6.  Are digital circuitry, relays, or squibs on the same ground?

7.  Is the isolation inadequate between tied power sources of different
    potential?

8.  Are power supply and associated grounds at different reference
    points?

9.  Are there any undesired capacitor discharge paths?

10. Are there momentary undesired current paths present during change of
    state or switching circuits?

[SNEAK TIMING]{.underline}

11. Do circuits experience unintended modes or false outputs during
    power-up?

12. Do digital signals sharing a common source and load split and later
    recombine?

13. Are consecutive digital devices powered from different supplies?

14. Are noise margin limits exceeded for digital devices?

15. Do resistor-capacitor networks in digital circuits provide the
    required characteristics, such as pulse width and switching speed?

16. Do large resistor-capacitor time constants cause excessive rise or
    fall times in switching circuits?

17. Are there momentary undesired current paths during change-of-state
    of switches?

18. Do relay coils have a single standard diode with a zener diode in
    series for transient suppression?

19. Does high output impedance of transistor-to-transistor logic (TL)
    devices cause an excessive resistor-capacitor time constant?

20. Are there any ground paths to transistor-transistor logic (TTL)
    devices inputs (momentary or otherwise) which can turn the device
    on?

21. Does turn-on, turn-off, or open-close timing of any device cause a
    problem in its application?

22. Are there timing gaps (break-before-make) or overlaps
    (make-before-break) in switching circuits?

23. Are command lines adjacent to power line?

24. Does the capacitance of a line cause excessive "skew" of the signal
    in it?

[SNEAK INDICATIONS]{.underline}

25. Does an indicator monitor a command of a function rather than the
    function itself?

26. Does an indicator circuit depend upon the function it monitors for
    proper operation?

27. Does a load perform an undesired function?

28. Can a press-to-test circuit energize a system?

[SNEAK LABELS]{.underline}

29. Are all labels compatible?

30. Does the label reflect the true function?

APPENDIX D

POTENTIAL DESIGN CONCERNS

This appendix is not a mandatory part of this standard.

1.  Do uncommitted switching device outputs drive other switching
    circuitry?

2.  Is there a ground-to-output on transistor-to-transistor logic (TTL)
    devices?

3.  Do compatibility requirements differ at the interface of two
    integrated circuit technologies?

4.  Is fan-out of digital devices exceeded?

5.  Are input voltage or current requirements to semiconductor devices
    exceeded?

6.  I any circuitry unused or unnecessary?

7.  Are any relay coils unsuppressed?

8.  Are any test points unprotected, i.e., lacking isolation resistance?

9.  Do amplifiers or comparators have capacitors greater than 0.1
    microfarads connected from input to ground or as feed back elements
    without series limiting resistance?

10. Do comparators have capacitors greater than 0.1 microfarads
    connected from output to ground without series limiting resistance?

11. Do operational amplifier inputs see unequal impedance?

12. Do spare inputs of integrated circuit devices have open circuit
    inputs?

13. Do complimentary metal oxide semiconductor (CMOS) devices have
    inputs feeding off the circuit card without pull-up or pull-down
    resistors?

14. Do large scale transistor-to-transistor logic (LSTTL) devices have
    spare inputs connected to used inputs of the same gate?

15. Are differentiator circuits used?

16. Do integrated circuit devices or transistor-transistor logic (TTL)
    devices have any open inputs or gates.

17. Do operational amplifiers lack bias current resistors or have
    resistors with improper values?

18. Are any unused operational amplifiers not in a unity gain
    configuration with all inputs grounded?

19. Do relay coils have single standard diodes for transient
    suppression?

20. Is the noise margin less than 0.5 volts at inputs for large scale
    type logic devices?

21. Is a transistor operating in the saturated region?

22. Are any digital devices improperly biased?

23. Do any capacitors have maximum charge or discharge currents that can
    damage other components?

24. Is V~in~ of an integrated circuit greater than V~cc~?

25. Are any integrated circuit inputs or outputs unsuppressed?

26. Is available energy insufficient to "blow" a squib component?

27. After firing, can the squib component short or open?

28. Is static energy protection for squib components lacking?

29. Is "no-fire" current protection lacking for squib components during
    checkout test?

30. Is a squib component without a current limiting resistor?

31. Can the forward resistance of a diode affect charging and
    discharging times?

32. Are there potential reverse voltages which can damage tantalum
    capacitors?

33. Can a semiconductor controlled rectifier turn on prematurely?

34. Are lamps without isolation fuses?

35. Can "cross-talk" adversely affect signals in adjacent wires?

36. Are power switching transistors subject to damage of inductive
    switching spikes?

[DRAWING ERRORS]{.underline}

37. Are any devices shown with power, signal, or ground connections
    missing?

38. Do parts, components or interfaces on a drawing disagree with other
    drawings that represent different indenture levels or are
    continuation sheets?

39. Does the parts list disagree with the drawings?

40. Is a tantalum capacitor shown connected incorrectly?

41. Is there a lack of dynamic stability?

42. Are there deficient parts as evidenced by:

```{=html}
<!-- -->
```
a.  Failures of a generic or chronic character,

b.  Limited capability substitute parts,

c.  Over stressed parts?

```{=html}
<!-- -->
```
43. Is there a single multi-pole relay carrying redundant functions?

44. Is there unintended thermal coupling between high dissipation or
    heat sensitive elements?

45. Are harnesses, connectors, and tie points shared in common by
    otherwise redundant paths?

46. Are there sympathetically induced failures such as common heat sink
    and electrical path for transistors, rectifiers, and blocking
    diodes?

47. Are redundancy paths integrated into a common multi-layer printed
    circuit board?

48. Is redundancy negated due to sneak paths embodied in sensors or
    signal processing circuits?

49. Does command logic and execution hardware form a single point
    failure site for pyrotechnic or ordnance devices?

50. Is there sharing of fuses?

51. Is there sharing of redundant items, such as:

```{=html}
<!-- -->
```
a.  Common power supplies or converters,

b.  Common power lines and returns,

c.  Jumpered signal points,

d.  Common printed wire traces

e.  Common connectors and pins?

```{=html}
<!-- -->
```
52. Are multi-functional parts, such as dual transistors, dual
    integrated circuits, or quad integrated circuits shared in redundant
    paths or alternate modes of operation?

53. Are printed circuit board traces and wires properly derated?

54. Are there common line decoupling capacitors?

55. Are there single line decoupling capacitors or blocking diodes?

56. Could there be structural or mechanical failure of housings (and
    support structure) containing redundant items?

57. Are there microwave device failure modes which degrade electrical
    performance of companion redundant devices via poor isolation, high
    voltage standing wave ratio, or noise generation?

58. Are there common jacks, pins, and connectors on splitters or
    dividers upstream from redundant items?

59. Can a failure in one experiment result in spacecraft failure in
    multiple payload spacecraft?

60. Is there exposure of redundant elements to a single failure
    stimulus?

61. Is there an inability to detect a failed item?

62. Can erroneous commands be induced by human error or software?

63. Can test equipment or other AGE induced failures?

64. Are there overstress mechanical failures?

65. Are there overstress electrical failures?

66. Are there overstress thermal or thermal cyclic failures?

67. Are there corrosion, electrochemical, or physicochemical failures?

68. Are there contamination, plume impingement, outgassing and related
    failures?

69. Have the effect of body bending on control and stability been
    properly addressed?

70. Have the effect of fluid sloshing been properly addressed?

71. Have the inertial and coupling effects of masses been properly
    addressed?

72. Is there adequate venting?

73. Has the possibility of multipacting breakdown been properly
    addressed?

74. Has the possibility of corona breakdown been properly addressed?

75. Has the possibility of fatigue been properly addressed?

76. Is there inadequate shielding or improper parts application that may
    lead to radiation damage?

77. Are there microwave material or construction deficiencies resulting
    in generation of intermodulation products (IMP).

78. Can events which terminate or seriously degrade performance or which
    constitute a safety hazard be caused by fewer than two distinct
    actions?

79. Are there inadequate keying, clocking, size variations, or harness
    installations permitting crossmating of printed circuit boards,
    electrical, hydraulic, ordnance, or other connectors?

80. Can there be a repeat of past design weaknesses due to inadequate
    review of available histories of similar equipments and designs?

81. Can there be electromagnetic compatibility or electromagnetic
    interference failures?

THIS PAGE INTENTIONALLY LEFT BLANK

APPENDIX E

APPLICABLE DATA REQUIREMENTS

This appendix is not a mandatory part of this standard.

10. [CONSIDERATION OF DATA REQUIREMENTS]{.underline}.

> This following data requirements should be considered when this
> standard is applied on a contract. The applicable Data Item
> Descriptions (DID's) should be reviewed in conjunction with the
> specific acquisition to ensure that only essential data are
> requested/provided and that the DID's are tailored to reflect the
> requirements of the specific acquisition. To ensure correct
> contractual application of the data requirements, a Contract Data
> requirements List (DD Form 1423) must be prepared to obtain the data,
> except where DOD FAR Supplement 27.475-1 exempts the requirement for a
> DD Form 1423.

[Reference]{.underline} Suggested

[Task]{.underline} [DID Number]{.underline} [DID Title]{.underline}
[Tailoring]{.underline}

101 DI-R-7079 Reliability Program Plan None

102 DI-R-7079 Reliability Program Plan None

103 DI-A-7088 Conference Agenda None

DI-A-7089 Conference Minutes None

104 DI-RELI-80255 Report, Failure Summary None

and Analysis

DI-QCIC-80125 ALERT/SAFE ALERT None

DI-QCIC-80126 Response to an ALERT/SAFE ALERT None

DI-RELI-80253 Failed Item Analysis Report None

201 DI-RELI-80686 Reliability Allocations

Assessments, and Analysis Report None

202 DI-RELI-80686 Reliability Allocations

Assessments, and Analysis Report None

(continued from previous page)

[Reference]{.underline} Suggested

[Task]{.underline} [DID Number]{.underline} [DID Title]{.underline}
[Tailoring]{.underline}

203 DI-RELI-80686 Reliability Allocations,

Assessments, and Analysis Report None

204 DI-R 7086 FMECA Plan None

DI-RELI-80687 Report, Failure Mode and Effects

Analysis (FMEA) None

205 DI-RELI-80686 Reliability Allocations,

Assessments, and Analysis Report None

206 DI-R-7084 Electronic Parts/Circuits

Tolerance Analysis Report None

208 DI-RELI-80685 Critical Items List None

209 DI-RELI-80686 Reliability Allocations,

Assessments, and Analysis Report None

210 DI-RELI-80686 Reliability Allocations,

Assessments, and Analysis Report None

301 DI-RELI-80249 Environmental Stress

Screening Report None

DI-RELI-80251 Reliability Test and

Demonstration Procedures None

302 DI-RELI-80250 Reliability Test Plan None

303 DI-RELI-80250 Reliability Test Plan None

304 DI-RELI-80251 Reliability Test and

Demonstration Procedures None

DI-RELI-80252 Reliability Test Reports None

The DID's listed were those cleared as of the date of this standard. The
current issue of DOD-5010.12-L, Acquisition Management Systems and Data
Requirements Control List (AMSDL), must be researched to ensure that
only current, cleared DID's are cited on the DD Form 1423.