ISS Reliability Overview.pdf

Overview of ISS Reliability and Maintainability

Sponsoring Org/Office Code: UA/OE Date:1/28/2025

Thomas (Van) Keeping

S&MA

Page No. 1

ISS R&M Overview

• Key Requirements Early NASA R&M work that was later discontinued or transitioned to another org

• Reliability • Reliability Block Diagram Analysis (RBDA)

• Stage (RBDA) • Failure tolerance

• Reliability and Maintainability Assessment Tool (RMAT)/ Traffic Modeling • Microgravity Reliability

• Maintainability

• Design Features

• Mean Maintenance Crew Hours

• FDIR/ Ambiguity resolution requirements (Primary responsibility transitioned to Station Management and Control)

• Key deliverables

• Failure Modes and Effects Analysis (FMEA) and Critical Items List (CIL), (SM04)

• Requirements for FMEAs are capture in SSP 30234 H

• ISS FMEA requirements have their roots in Mil-STD-1629A and Orbiter FMEA requirements

• ISS FMEAs are located and configuration controlled in the ISS FMEA system

• S&MA Allocations, Assessments, and Analyses (AAA) Reports, (SM05)

• Requirements are captured in the DRD (Includes MTBF, MTTR, LLI, PM, etc.)

• Data is configuration managed in ISS MADS system

Page No. 2

ISS Reliability and Maintainability (R&M) Functions

• Provides assurance such that a programmatic requirements are levied on the hardware provider.

• Assessment of ISS hardware and connectivity to ensures ISS is both reliable and maintainable

• Activities under the R&M requirement/verification are:

• Requirement Assessment: kicks off as new documents are released or when a modification that involves upgraded hardware emerges.

• Assess applicability of the requirement based on item functionality. Assures requirement properly addresses to the top-level ISS specification.

• Requirement Verification: R&M to review design team verification reports to ensure per ISS specification verification method (by analysis, testing or inspection), resolve any issue for approval through VCN.

• R&M Qualitative/ Quantitative Maintainability Analysis: This effort involves assessment of maintainability requirements

• Visual access of fluid lines, temporary restraint and Proper installation and removal of equipment

• Review by analysis of drawings, inspection and data obtained from demonstrated test.

• Ensure Total Mean-Maintenance-Crew-Hours-per-Year (TMMCH/Y), not exceed the times allocated.

Page No. 3

Requirements (SSP 41162)

3.2.3 Reliability.

3.2.3.1 Failure tolerance.

a. The on-orbit USOS failure tolerances shall be no less than the allocation in Table XXXI, column 2, for the identified segment functions with the exceptions identified in appendix B.

b. When the on-orbit USOS capabilities are implemented using structure (see 6.1), the structure shall be exempted from the failure tolerance requirement.

3.2.3.2 Failure propagation.

A single failure of an ORU in a functional path shall not induce any other failures external to the failed ORU. (Exceptions- removed to improve readability)

3.2.3.3 Separation of redundant paths.

Alternate or redundant functional paths shall be separate or protected such that any single credible event which causes the loss of one functional path will not result in the loss of the redundant functional path(s).

3.2.3.4 Redundancy status.

Redundant functional paths shall permit the ascertaining of their operational status without the removal of ORUs.

Page No. 6

FMEA Purpose

• Identify and classify hardware functions and ensures the critical functions are available over the life of the Program

• Identifies and classifies hazardous failure modes and ensure that appropriate mitigations are in place

• The FMEA used as a part of the design process to identify non-compliances and high-risk areas. If risk cannot be eliminated, the FMEA forces identification and review of acceptance rationale that analyzes the following:

– Design, tests, and inspections

– Operational workarounds that can preclude the effect from occurring

– Maintainability of the item

– Failure history

• During the Hardware/ System Acceptance Phase the FMEA serves as a verification product for the following requirements :

3.2.3.1 Failure tolerance, 3.2.3.2 Failure propagation, 3.2.3.3 Separation of redundant paths, and 3.2.3.4 Redundancy status

• During the operations phase, the FMEA worksheets now serve as official program documentation for hardware failures and provides the following:

• Types of failures that can occur and if they are detectable

• Causes that contribute to the failures

• Worst case effect on the item, systems, end item, mission, crew, and ISS.

• Time to Detect, and Time to Effect

• Acceptance rationale for failures assessed “Critical Items”

• FMEAs are maintained over the life of ISS and approved by NASA R&M

Page No. 7

ISS FMEA Processing

• At PDR, the FMEA shall address each system/subsystem at the functional level, as a minimum. If redesign is not practical, those functions that meet the criteria specified in Paragraph 6.1 (Paragraph 8.0 for GSE) shall be suitably documented in the preliminary CIL.

• At the CDR, the CIL shall be evaluated. This evaluation will result in a preliminary indication of which items will be considered for program acceptance (accepted risks), and which items must be redesigned. Design options shall be presented early during the design phase to minimize any cost or schedule impact to redesign hardware and/or software. The integrated CIL shall be retained as the interim program CIL until each of the items on the CIL is either baselined via program approval or are removed from the CIL based on a design change.

• As a result of the CDR, actions will take place to implement design changes or to prepare CIL program acceptance documentation for critical items. In the cases where design changes are not required, but where items would still remain on the CIL, appropriate program acceptance documentation shall be developed using the retention rationale previously identified in the CDR CIL. Any required corrections to the retention rationale shall be made.

• Prime is responsible for the preparation of an integrated FMEA and integrated CIL (reference Paragraphs

3.2.2.1 and 3.2.2.2). The integrated FMEA shall be assembled from the FMEA information provided by the hardware providers.

Page No. 8

What is an Initial Assessment of Criticality (IAC)?

• “Short version” of FMEA

• Used to provide early identification of criticality as “criticality” of hardware is often needed to baseline requirements for “Electrical, Electronic, and Electromechanical Parts” and “Test and Verification.”

• Analogous to a Standard Hazard Report Form in that Common failure modes are analyzed

• Premature operation.

• Failure to operate within specification or failure to operate at a prescribed time.

• Failure during operation, including failure to contain or store energy or fluids.

• Failure to cease operation at a prescribed time.

• Results are used to determine whether a full FMEA is required

• Used in place of a FMEA when the item being analyzed is “off the shelf” or for simple items that do not affect Station core functionality.

Page No. 9

Critical Items

• A critical item (also called a CIL (Critical Items List)) represents a single failure point that results in the loss of a critical function (criticality 1, 1S, 2) or a redundant function with compromised redundancy

• Redundancy is compromised:

• When it is susceptible to common cause failure (i.e. Fails the Separation of Redundant

Paths Requirement)

• When hardware has to be removed to verify that the redundant function is available

• When the loss of a function cannot be detected and recovered prior to the critical event occurs

• Critical Items must be accepted by the Program

• Program acceptance can be as a standalone CIL, closed to a hazard report cause that addresses the failure mode/cause in question, closed to a program waiver and/or exception

Page No. 10

Failure Detection Isolation and Recovery (FDIR) Requirements

3.2.4.3 Failure detection, isolation, and recovery.

3.2.4.3.1 Data availability.

The USOS shall make available, to automatic capabilities and operators on demand: performance, configuration, status, out−of−tolerance, failure, and hazard data in accordance with SSP 41142, SSP 41150, paragraph 3.1.5, SSP 41151, paragraph 3.2.2.2, SSP 41154, SSP 41175−10, SSP 42003, SSP 42007, SSP 42016, and SSP 42121.

ICDs (Primarily software) 3.2.4.3.2 False alarm mitigation.

The USOS shall confirm automatically detected out of tolerance conditions, failures, and hazards prior to declaring a permanent out−of−tolerance, failure, or hazard.

Page No. 11

3.2.4.3.3 Manual failure detection, isolation, and recovery.

The following categories of equipment shall utilize crew interaction or crew observation for manual failure detection, isolation, annunciation, and recovery:

a. Human/equipment interface such as visual display devices, cursor control devices, manual input devices.

b. General and specialized lighting.

c. Visual and aural caution and warning devices such as warning panel lamps/lights, speakers and volume controls.

d. Structural, mechanical, electromechanical, and electrical equipment that have no interconnection for data collection and transmission to the core computational data network. There is no intent to require special instrumentation for fluid, power, and data lines, structure, or manually operated equipment. See appendix B for the exceptions to this requirement.

e. One−time use equipment that has manual redundancy (crew intervention upon failure of automatic function) and is not intended to be maintained on−orbit during the life of the program such as bolt motor controllers for assembly operations.

3.2.4.3.4 Manual control of failure detection, isolation, and recovery.

The USOS shall provide for manual control of automatic detection, isolation, and recovery control processes.

Page No. 12

3.2.4.3.5 Automatic functional recovery verification.

The USOS shall automatically confirm restoration of functional performance after an automatic functional recovery.

3.2.4.3.6 Automatic safing verification.

The USOS shall automatically confirm a safe condition after an automatic safing action.

3.2.4.3.7 Testing at operation location.

The USOS shall detect and isolate failures and hazards that may manifest a catastrophic or critical hazard within 24 hours without removal of equipment from its operating location or use of ancillary test equipment. See appendix B for exceptions to this requirement.

3.2.4.3.8 Ambiguity resolution.

The USOS shall resolve failure isolation ambiguities to the following levels, excluding failure modes for wire harness assemblies and plumbing lines:

a. 90 percent of identified failure modes to 1 on−orbit maintainable unit,

b. 95 percent of identified failure modes to 2 on−orbit maintainable units, and

c. 98 percent of identified failure modes to 3 on−orbit maintainable units.

Page No. 13

Reliability and Criticality

• Reliability is inclusive of criticality and is focused on ensuring the ability of a system to perform its function over its expected life and understanding the risk associated with a system failure

• Criticality looks independently at two aspects of a failure to classify its consequence and then looks to see if the function is redundant

• Functional criticality - The criticality is assigned based on the identified effects on the Station/Crew. The Ground Rules and Assumptions document defines the assumptions used in relating functional loss to crew effects.

• Hazard based criticality - Failures with catastrophic hazardous effects unrelated to functional effects are documented in the FMEA with a criticality consistent with the hazardous effects and associated hazard report.

Note 1: Criticality assessments assume all inputs to an ORU are correct including commanding Note 2: Criticality assessments are based on a single credible failure within an ORU.

Note 3: Criticality tends to be a flashpoint because of its relationship with parts selection (SSP

30312 3.2.1), testing (SSP 41172 3.1, 8.1, 9.0), implications on software criticality (Class A software requirements), and PRACA (SSP 30223 3.3.1).

S&MA has team members familiar with navigating the exception process and is happy to help teams attempting to navigate it

Page No. 16

ISS Criticality nuances

• Functional criticalities for “enhancements” and “exploration demo hardware” create confusion

• Function is a high criticality but in addition to what is required by the segment specification (e.g. remove CO2)

• Per SSP 30234 hardware ends up being 1R

• Demo hardware integrated into core systems can become a higher criticality if its failure can result in loss of a high criticality core system function

• Multiple tweaks made to the criticality definitions and redundancy screens to refine what was a requirements violation

• Criticality 2N/2NRis an ISS only criticality developed to identify systems that are more important than criticality 3, but doesn’t rise to the level of a 1,1R, 1S, 1SR, 2, or 2R criticality

• Unique requirements in SSP 30234 identify specific examples (e.g. maintenance hardware/spares, exercise equipment, hardware protective failures for out of spec conditions)

Page No. 17

ISS Criticality nuances

Safety Definitions (SSP 51721)

CATASTROPHIC HAZARD

Any condition which may cause a disabling or fatal personnel injury or illness, or one of the following: loss of ISS, loss of a crew-carrying vehicle, or loss of a major ground facility.

CRITICAL HAZARD

Any condition which may cause a non-disabling personnel injury or illness, loss of a major ISS end item, loss of redundancy (i.e., with only a single hazard control remaining) for on-orbit life sustaining function, or loss of use of systems needed for essential logistics (e.g., the SSRMS).

Safety Reliability Definition Issues

• Differing definitions between safety and reliability can create confusion between the teams that support both disciplines

• Multiple updates to the FMEA Requirements to right size the approach for hardware that wasn’t part of the Station’s core systems

• Reliability Criticality 1S/1SR hardware isn’t always a hazard control

• Emergency Response hardware can be an alert, additional safety feature, control, mitigation, and/or part of an emergency response

Reliability Definitions (SSP 30234) Category Definition (Potential Effect of Failure) 1/1R Failure that could result in loss of Space Station or life.

1S/1SR Failure of a system component designed to protect against a potentially catastrophic event or a single failure point in a safety or hazard monitoring system that causes the system to fail to detect, or operate when needed during the existence of a catastrophic condition that could lead to loss of Space Station or life (e.g., fire suppression, medical hardware).

2/2R Failure that could result in loss of critical mission support capability, as defined below.

The loss of critical mission support capability is defined as the following:

1. Complete loss of the microgravity environment provided by Space Station, (reference SSP 41000, Paragraph 3.2.1.1.4.1 Capability:

Support microgravity experiments), or loss of those critical functions that support microgravity racks (e.g., power and thermal).

2. Complete loss of access to the vacuum environment of space.

(Note: Failures that result in loss of one element’s vacuum access are not considered mission loss.)

3. Loss of a visiting vehicle mission.

Page No. 18

Qualitative Reliability Process Issues

• Accuracy and validity of data

• Configuration management

• Assembly and changing functionality

• Design augmentation/ Mod Kits

• Engineering engagement

• Overlapping risk acceptance

• Critical Items

• Hazard reports

• Interpretation of Separation of Redundant Paths Requirement

• How to verify Failure Propagation Requirements

Page No. 19

Qualitative Maintainability Requirements (SSP 41162)

• THE R&M team reviews the design, ensures that requirements are levied as appropriate, and reviews verification data to ensure that ISS qualitative analysis requirements are met

3.2.4 Maintainability.

3.2.4.1 Qualitative maintainability design.

Hardware and software shall be maintainable to allow functions to be reinstated or restored throughout the intended operational life of the on-orbit Space Station.

3.2.4.1.2 Nonpressurized area access for inspection.

USOS equipment designed for on-orbit maintenance in nonpressurized areas shall have the capability to permit inspection while in the installed position without requiring the removal of other equipment. Removal or opening of protective covers such as micrometeoroid/orbital debris shield and thermal blankets is permissible.

3.2.4.1.3 Installation/removal.

3.2.4.1.3.1 Equipment item interconnecting devices.

USOS shall provide utility line attachment/mounting length to allow removal/replacement of the equipment item.

Page No. 20

Qualitative Maintainability Requirements (SSP 41162)

3.2.4.1.3.2 Incorrect equipment installation.

USOS equipment shall contain physical provisions to preclude incorrect installation. See appendix B for exceptions to this requirement.

3.2.4.1.3.3 Lockwiring and staking.

No USOS planned maintenance equipment installations or operational interfaces shall be lockwired or staked.

3.2.4.1.3.4 Fluid capture and containment.

USOS liquid systems installations in pressurized volumes shall be compatible with fluid capture and containment methods used for fluid release during maintenance.

3.2.4.1.3.5 Restraining and handling devices for temporary storage.

a. In a microgravity environment, USOS external equipment shall allow for restraining and handling by robotic devices to provide temporary storage.

b. The internal equipment shall allow for restraining and handling for temporary storage by the crew.

Page No. 21

Preventative Maintenance and Limited Life Items

• Limited life Item is a piece of hardware that will not meet its 10-year life (some hardware will have a specified 15-year life) or has other life limiting characteristics (Cycle life, shelf life, operational life, wetted life, etc.)

• Limited Life Items can be “run to failure” (e.g. GLA) or removed and replaced prior to failure (SPCU HX)

• Both are accounted for in Logistics sparing analysis

• LLIs that are not “run to failure” are tracked as PMs

• Items may have their life extended/updated based on test, analyses, and/or TTE

• Limited Life Item requirements are captured in MADs. Individual Serial numbers are tracked by Logistics in Gold

Page No. 22

Preventative Maintenance and Limited Life Items

• Preventative Maintenance requirements are captured in MADS

• Preventative Maintenance actions are taken to ensure that a function continues operate with no to minimal down time

• PM’s fall into two main buckets

• Service and inspect maintenance actions

• Can trigger condition based corrective maintenance

• Typical operations lubrication, inspection, and/or cleaning

• Remove and replace maintenance (Battery replacement, filter changeout)

• Preventative Maintenance actions by SN are tracked in GOLD and scheduled in Annex 2 of the IDRD

• Note: Housekeeping actions are low criticality PM-like tasks tracked separately in the annex 2

• PM and LLI data is updates over the life of the station

Page No. 23

Reducing PM

• Some level of PM/housekeeping is unavoidable

• Human habitation generates dust and debris

• PMs are created to address unexpected hardware issues

• PMs are implemented as part of the tradeoff between cost, schedule, mass, safety, reliability, and volume

• Can implement a larger capacity filter that will last the design life of an ORU, but will be larger and heavier

• Can add cameras or remote reporting/detection to hardware, but that adds cost and complexity

• IVR is a possibility, but is costly and complex

• Can accept risk and extend PM times

Page No. 24

Early Space Station Freedom Maintenance Assessments

• Fisher-Price

• As part of the design requirements for Space Station Freedom (SSF) NASA allocated a maximum of 130 crew-hours per year for both Station EVA preventative and corrective maintenance.

• In 1989, the NASA Space Station Program Office (Cramer group) performed a study which indicated that more than 1732 crew hours per year (including maintenance uncertainties and the overhead) would be required for EVA maintenance (equivalent of 2.8 two-man EVAs per week)

• EVA time estimate was based on preliminary failure rate and repair time data.

• Since this EVA time requirement appeared prohibitive JSC established the Space Station

Freedom External Maintenance Task Team (EMTT) under the direction of William Fisher and Charles Price (hereafter interchangeably called the EMTT and the Fisher-Price team) to refine the estimated EVA maintenance requirements.

Page No. 26

Early Space Station Freedom Maintenance Assessments

• Fisher-Price Recommendations

• Creation of The ORU Database

• The database created by this task team in response to the need to tabulate external ORUs is an essential reference tool for the program and should be continued. In addition, a common nomenclature for uniquely identifying each ORU does not yet exist and should be developed and baselined throughout the Space Station Program. The ORU database enables rapid software incorporation of ORU updates and design changes as they occur and can facilitate the development of a maintenance and logistics strategy for the Space Station.

• Fisher-Price Orbital Replacement Unit (ORU) Database

• Identify the number of ORUs

• Compare mean time to complete a task (MTTR) to task frequency (MTBF)

• Identify candidate items for standardization

• Estimate extravehicular activity (EVA) and robotic time

• Perform advanced statistics and simulations

• Provide simple reports

Page No. 27

S&MA Allocations, Assessments, and Analyses (AAA) Reports

• Key Requirements

3.2.3.2 QUANTITATIVE RELIABILITY. (SSP 41000) (officially closed) The on-orbit Space Station functions shall be capable of operating in the microgravity mode, as defined in

3.2.1.1.4 and Table V, for 30 day continuous periods per the mission profile shown in Figure 7 with a reliability of 0.80 (see 6.1).

3.2.4 Maintainability.

3.2.4.1.1 Nonpressurized area equipment maintenance time.

USOS equipment in nonpressurized areas shall be such that the maintenance worksite time, from setup to teardown, does not exceed 3 hours. The total elapsed maintenance task time, from egress to ingress, does not exceed 6 hours. (Worksite tasks exceeding 3 hours should be partitioned and safed.)

3.2.4.2 USOS mean maintenance crew hours per year. (SSP 41162) The USOS shall not exceed the Mean Maintenance Crew Hours per Year (MMCH/Y) resource allocation of

266.2 MMCH/Y for IVA, 143.7 MMCH/Y for EVA, and 165.6 MMCH/Y for Extravehicular Robotics (EVR).

• From the requirements above the following data is generated to capture MTBF’s MTTR’s, PMs, PM time, LLI, k-factors, etc.

• Data is maintained and utilized by Logistics, engineering, PRA, and Reliability

Page No. 28

Reliability Predictions and MTBF Bayesian Updating

• Reliability Predictions presented during design reviews (SRR, PDR, CDR, etc.)

• Most are based on Mil-HDBK-217 and the Non-electronic Part Reliability Data (NPRD) (suggested method in the Boeing Supplier Data Sheet)

• On-orbit experience to date has shown (on average) that the Mil-HDBK-217 methodology has yielded conservative results

• L&M provides a Bayesian MTBF update to various ISS system hardware components that require it as a result of on-orbit failures reported by the subsystem managers (SSM) and their respective Subsystem Problem Resolution Teams (SPRT)

• Results of the MTBF updates are presented to the R&M Working Group for official approval and inclusion into the MADS database with the aid of the R&M team Approval process involves coordination with respective ISS vehicle safety engineers

Page No. 29

Hardware MTBF’s and k-factors

• Mean Time Between Failures or MTBFs are the predicted failure rates

• Failure rates are calculated using Mil-Hdbk-217 (old handbook that provides conservative Predictions) and the Nonelectronic Parts Reliability Data Publication

(NPRD-XXXX)

• K-Factor is a scaling factor that is multiplied with the base failure rate to account for failures that are externally induced in the hardware (includes failures caused by crew actions, MMOD, etc.)

• K-Factors are based on hardware type and originated from the Freedom era Fisher- Price Study

• Both MTBFs and k-factors are updated through a process called Bayesian updating twice a year based on operational time and failures experienced

• The failure rate data is used in PRAs and in the Functional Availability and Sparing Analysis (FASA)

Page No. 30

What is MADS?

• MADS is the ISS Maintenance Analysis Data Set (previously known as the Modeling Analysis Data Set)

• MADS is the ISS Program Repository for the following data/requirements

• Preventive Maintenance (PM) Data (types, requirements, frequency, and times)

• MTTR, Overhead times by operation

• Limited Life Item (LLI) data

• Reliability Predictions (OEM and operational)

• Duty Cycle, Operating Hours, Failures (induced, inherent, wearout)

• K-Factors (OEM and operational)

• The data is managed by the ISS Reliability and Maintainability Team and used by the following teams:

• The Logistics Increment Planning team uses it for planning on-orbit maintenance

• The Logistics GOLD database team tracks when maintenance is due and last performed both on-orbit and on the ground

• The Logistics Strategic Analysis Team is responsible for determining the number of spares required to support a functioning ISS through end of Program

• ISS Program Risk team uses the MTBF information for their PRA Assessments

Page No. 31

What is the source of the data in MADS?

• Initial PM and LLI data is provided by the hardware development team and is revised based on on-orbit performance

• LLI and PM assessments are based on OEM recommendations and application analysis

• K-Factor is a scaling factor that is multiplied with the base failure rate to account for failures that are externally induced in the hardware (includes failures caused by crew actions, MMOD, etc.)

• K-Factors are based on hardware type and originated from the Freedom era Fisher-Price Study

• OEM Reliability Predictions

• Most are based on Mil-HDBK-217 and the Non-electronic Part Reliability Data (NPRD) (suggested method in the Prime Contractor Supplier Data Sheet)

• On-orbit experience to date has shown (on average) that this methodology has yielded conservative results

• Some of the original predicted data dates back to the Freedom Program

• Duty Cycle

• Duty cycle originally based on prelaunch predictions, but have been update to reflect actuals

• MTTR, Overhead times by operation (EVR, IVA, EVA)

• Data is generated primarily from the LSAR analysis

Note: the size and dimension data in MADS is not currently maintained and reflects the best available data

Page No. 32

Why Update the data?

• Program Risk Assessments (PRA) and L&M Planning relies on predicted failures and scheduled maintenance based on LL and PM Predictions

• Close out of the shuttle program limits number and placement of spares

• Accurate prediction of the Failure Rates of key ORUs is needed

• Bayesian updating is used for MTBF’s because it can be done with zero or a low number of failures

• Maintenance planning is an important part of increment planning

• Allows for maintaining critical functions while allocating time for science

Page No. 33

“Operational” data

• Original predictions are updated in “operational” fields to reflect on-orbit experience

• MTBF’s are updated using a Bayesian technique that allows the Reliability and Logistics team to incorporated on-orbit experience even when no failures were experienced

• K-factors are updated by using a heuristic analysis to better fit the predicted data to observed performance

• MTTR’s are updated based on on-orbit performance

• PM times are updated based on on-orbit performance

• PM’s and PM frequencies are updated based on on-orbit trending performance and Test, Teardown, and Evaluation (TT&E) of returned items

• New PM’s are added based on system performance and failure analysis

Page No. 34

Failure and Operational Hours

• Inherent failure

• Failure is determined to be a random failure and not attributed to an external event

• Wear-out Failure

• Failure occurs near MADS predicted “Life Limit”

• caused by repetitive stress, wear and tear

• Induced Failure

• induced by crew, environment, other equipment, or false failure indication

• Operational Hours estimated by:

• Hours = 24*DC*(n*(current date - activation date) – down-days)

• n = quantity of ORUs in activated group

• DC = observed Duty Cycle

• fraction of total time that the ORU is typically used

• does not include cold spare (keep-alive power) time

• Operating hours and failure counts updated every 6 months

Page No. 35

Reliability and Maintainability Working Group (R&MWG)

• The R&MWG is chaired by the R&M Lead and core membership includes contractor Reliability Managers

• Ad hoc membership based on topic includes Logistics, EVA, Engineering, FOD, and Space and Life Sciences

• R&MWG is convened on ad hoc basis to address the following:

• The R&MWG addresses issues raised during the review of FMEAs and IAC (Initial

Assessment of Criticality)

• Review Critical Items and refer to the SMACB as required

• Critical items closed to Hazard reports are approved by a memo signed by the R&MWG Chair and the Responsible SRP Chair

• Critical Items closed to waivers are closed the board decision used to approve the riskFMEAs

• Establish PM/LLI requirement baseline (based on provider analysis) and updates

• Approve Reliability Predictions and updates

• Address technical issues related to R&M

• Most R&M products are reviewed and approved Outside of Board

Page No. 38

Quantitative Reliability Process Issues

• Accuracy and validity of data (MTBF, MTTR, PM, LLI)

• Bayesian updating and having the data to support the analysis

• Configuration management

• Design augmentation/ Mod Kits

• Redesigned/ Systems and mixed fleet

• Cumulative Crew Time impacts

• Crew time allocations based on core systems

• Crew actions/PM/inspections serving as a band aid for design deficiencies

• Managing battery powered and calibrated equipment

Page No. 42

Back-up Slides

Page No. 43

FDIR Worksheet Data Elements (cont)

Isolation for Recovery: LSAR Reference - Provide a reference to the LSAR that documents the procedure for manual isolation to the recovery level.

Isolation for Maintenance: Ambiguity Level 1/2/3/>3 - Specify the ambiguity level (1, 2, 3 or greater than 3 maintenance units) that Isolation for Maintenance will be able to achieve.

Isolation for Maintenance: A/M/N - Specify whether Automatic, Manual or No isolation to the maintenance level is provided for the failure mode.

Isolation for Maintenance: Algorithms - Describe the algorithm (including sensor/system states) used to Isolate the failure mode to the maintenance level. Map the sensor/system states to their respective software Part II PUI number(s).

Isolation for Maintenance: LSAR Reference - Provide a reference to the LSAR that documents manual isolation to the maintenance level procedures.

Recovery: A/M/N - Specify whether Automatic, Manual or No on-orbit recovery is provided for the failure mode.

Recovery: Algorithms - Describe the algorithm (including sensor/system states) used to recover the function lost as a result of the failure mode. Map the sensor/system states to their respective software Part II PUI number(s).

Recovery: LSAR Reference - Provide a reference to the LSAR that documents manual recovery procedures.

Safe: A/M/N - Specify whether Automatic, Manual or No on-orbit safing is provided for the failure mode.

Safe: Algorithms - Describe the algorithm (including sensor/system states) used to safe a hazard that results from the failure mode. Map the sensor/system states to their respective software Part II PUI number(s).

Safe: LSAR Reference - Provide a reference to LSAR that documents manual safing procedures.

Page No. 45