Level Of Repair Analysis (LORA)

1. Level Of Repair Analysis(LORA) EMIS 7305 Ibrahim Malaika Vivek Raghuraman

2. Level Of Repair Analysis (LORA) • The level of repair analysis is instrumental in providing an optimized maintenance based upon a cost rational. • The analysis can be implemented as a standalone analysis. • Generally its integrated in the logistics support analysis. • The LORA process based on economic and non economic rational.

3. LORA Process • The LORA is considered as a two stage process to determine the item where it should be repaired and in which level: • Economical LORA (ELORA): the objective is to determine the optimum cost of repair of an item. • Non Economical LORA: is based on predefined questions this process is responsible for the maintenance strategy and level of repair for each task and determine whether the item should be repaired or replaced.

4. Logistic Support Analysis (LSA) • The LSA process is tailored in accordance with the maturity of the system design. Its provides a foundation for the Integrated Logistics Support program by generating source data and maintenance plans. • There are inputs to the LSA process such as: LSA plan, customer data, concept, supportability issues, subcontractor data, and engineering data.

5. Logistic Support Costs Normal Discount Factor: For expenditures occurring as equal payment series starting one year hence and terminating at the end of the life cycle. Present Discount Factor: For expenditures occurring as equal payment series starting at present and terminating one year prior to the end of the life cycle. Reduced Discount Factor: For expenditures occurring as equal payment series starting at present and terminating one year prior to the end of the life cycle.

6. LORA Strategy The selection of LORA tasks and degree of their accomplishment is based on the following factors: • The probable design, supportability and operational approaches for the system undergoing LORA • The availability, accuracy and relevance of LORA input data required to perform the proposed LORA Tasks • The potential design impact for LORA Recommendation • The LORA requirements specified in the SOW. • LORA Efforts conducted during previous phases of the acquisition program • Related system engineering analysis planned and completed which are still relevant.

7. LORA Tasks and Data – How they interface? The LORA description will include analysis and data interfaces with the following programs as applicable: • Design Program • Reliability program • Maintainability program • LSA and LSAR Program • Human Engineering Program • System Safety program • Maintenance Engineering planning and analysis program. • Support Equipment identification program • Standardization program • Parts Control Program • Packaging, handling, Storage and Transportability program. • Initial provisioning program • Warranty program • Test and evaluation program • Facilities program • Technical publications program • Survivability and Vulnerability Program • Corrosion Prevention Program • Other related Programs.

8. Reliability Engineering • The approach to reliability engineering will in part depend on the type of technology used, program objectives and requirements. These technologies include electronic, electrical and mechanical items or systems. • The main focus of this section is to provide information on some of the classical qualitative and quantitative reliability analysis used by the automobile, defense, and space industry. The analyses used in the world of reliability engineering include the following: 1. Reliability Programs. 2. Failure Modes and Effects Analysis (FMEA/ FMECA). 3. Reliability Predictions. 4. Reliability Block Diagrams. 5. Failure Reporting and Corrective Action System.

9. Reliability Programs • The approach to a reliability and maintainability program is dependent upon many factors that include the customer's requirements, the business strategy of the company, and the size of the project. The effective implementation of an R&M Engineering Program must take into consideration these and other factors.

10. Reliability and Maintainability Program Requirement • Customers requirements: The customer may request specific R&M engineering tasks to be implemented. This may include the development of reliability and maintainability models, or reliability and maintainability testing, to collected field data. Availability analysis could also be a requirement. • Company Strategy: The main concern to a company could be to adopt a strategy to develop a reliable and maintainable product. A key business objective must be to provide a product, which is highly reliable and maintainable

11. Reliability and Maintainability Program Plan • Program requirements: Specify what the program R&M requirements are, in terms of quantitative and qualitative objectives and also the required R&M engineering activities. • Program scope and objectives: Define the limitation of the program in terms of scope, detailing the main objectives. • Program Management: Detail the general program management effort, in terms of Work Breakdown Structure (WBS) and program schedule, showing relationships through organization charts to other key program players and with the customer. • Program Tasks: Detail the actual R&M program tasks that will be implemented, making reference to the specific requirements and specifications.

12. Reliability and Maintainability Program Plan • Interface with design engineering and other groups: Identify the interface particularly where critical inputs are required. These inputs could be in the form of program milestones and engineering support data. • Interface with the customer or end user: This interface can be captured by working group reviews, telephone hot lines and status reports. • Interface with Subcontractors: Depending on the involvement and level of effort required from a subcontractor, key information required may be the Point-of-Contact, their deliverables and the schedule tied to their deliverables. • Delivery schedules: List the deliverables that are required this maybe the results or reliability and maintainability analyses and testing results.

13. Reliability and Maintainability Program Tasks • Program Control. • What is required. • Program reviews. • Customer Liaisons. • Subcontractor Controls. • Engineering Interface. • Design Impact and Evaluation. • Design Criteria. • Tradeoff analyses. • R&M Modeling. • Failure Modes and Effects Analyses. • Design Verification

14. FMECA & FMEA • This the Failure Modes and Effect Analysis, commonly referred to a FMEA, is one of the most utilized methods for conducting reliability analyses. The Failure Modes and Effects Criticality Analysis (FMECA) is really an extension of the FMEA, focusing on the quantitative parameters for a criticality assigned to each probable failure mode. • FMEA is a powerful design engineering aid, and is used in the aerospace, military, automotive and space sectors. • The Failure Modes and Effect (Criticality) Analysis is termed as a bottoms up analysis. The FMEA is based on an qualitative approach, whilst the FMECA takes a Quantitative approach and is an extension of the FMEA, assign a criticality and probability of occurrence for each given failure mode.

15. Reliability Block Diagrams • A system's overall reliability can be determined by the development of reliability models. The complexity of these reliability models are dependent upon various factors such as mission profiles, function criticality, and redundancy characteristics. The general approach is to capture the modeling effort with the use of Reliability Block Diagrams.

16. Failure Reporting and correction active System • The Failure Reporting and Corrective Action System (FRACAS) commonly referred to a Closed Loop Reporting System, is instrumental in understanding how an equipment or system is actually performing in the field from a reliability (and maintainability) perspective. • The benefits of implementing FRACAS can be realized in a number of ways. A FRACAS can be of great importance to a manufacturer with respect to the operation and performance of a system. The manufacturer will see it in terms of how well their equipment or systems are performing in an operational environment.

17. Reliability Predictions • The reliability analyses can be used to define the quantitative parameters for an item, equipment or a complete system, and may be expressed in number of failures in a given set period of time, set number of cycles or set number of operations.

18. Maintainability Engineering • The maintainability engineering effort in the conception and design phase is critical to ensure that high system availability is obtained at optimum Life Cycle Support Cost. Key in the availability calculation of a system is its down time, the time required to bring a failed system back to its operational state or capability. This down time is normally attributed to maintenance activities. An effective way to increase a system's availability is to minimize the downtime. This minimized downtime does not happen at random, it is made to happen by actively ensuring that full consideration is given during the conceptual and design phase. Therefore the inherent maintainability characteristics of a system must be assured. This can be achieved by the implementation of specific design practices and validated through a maintainability assessment process, utilizing both analyses and testing

19. Maintainability Engineering • Some of the assurance activities: 1. Maintainability Programs 2. Maintainability Assessment 3. Maintainability Modeling 4. Maintainability Demonstration 5. Design for Maintainability 6. Defect Reporting and Corrective Action System (DRACAS)

20. Maintainability Assessment At the onset of a program it is important to identify the maintenance concept and derive the initial system maintainability requirements and design attributes. A maintainability assessment of a system or equipment is one method used to determine and validate the actual design taking into consideration the maintainability characteristics of the system. This could include performing an assessment of the: • Quantitative characteristics • Physical Characteristics

21. Maintainability AssessmentQuantitative characteristics • Quantitative characteristics:The quantitative characteristics that could be considered for a system, are it's specific maintainability performance characteristics and could include: 1. Mean-Time-To-Repair ( MTTR): It would be calculated taking into consideration the times needed to implement each of the corrective maintenance and preventative maintenance task for the system for each level of maintenance.

22. Maintainability AssessmentQuantitative characteristics 2. Maximum Time to Repair: An important element of the quantitative characteristics. 3. Built-In-Test (BIT): The establishment of the BIT capability is important. For example a system (mainly electronic) the principal means of fault detection and isolation to the LRU level requires the use of self-diagnostics or built-in-test. This capability, in terms of its effectiveness may need to be quantified. 4. Heath Status and Monitoring (HSM): Incorporated into the design of the system could be a HSM capability.

23. Maintainability AssessmentPhysical Characteristics • Physical Characteristics: The physical characteristics take in consideration the issues such as accessibility and the characteristics that will accommodate the maintainer's for ease of maintenance, and include: 1. Ergonomics: These characteristics would address the physical characteristics for the maintainer. Human Engineering Design Criteria for Military Systems, Equipment and Facilities, and Human Engineering Requirements for Military Systems, Equipment and Facilities provide good source when considering issues associated with human factors. This would range from the weight of components and required lifting points to the clearance between electrical connectors.

24. Maintainability AssessmentPhysical Characteristics 2. Mechanical Interfaces: May require specific criteria for interface issues such as mating and self-alignment, captive fasteners, access for tools, to keyed connectors. 3. Test Point: This effort must be interfaced with the testability engineering effort. A system may require some manual diagnostic interaction, where specific test points will be required for fault diagnostic and isolation purposes.

25. Maintainability AssessmentPhysical Characteristics 3. Test Equipment: This assessment would address how test equipment and tools would interface with the system or equipment. 4. Accessibility: Is an important attribute. As a system integrator the design of a system must avoid the need to remove other assemblies to gain access to a failed unit or the ability to permit the use of standard hand tools must be observed.

26. Maintainability AssessmentPhysical Characteristics 5. Reliability degradation: Caution must be given to reliability characteristics. A system required to provide a continuous service, by utilizing redundant elements should be safeguarded against any maintenance actions. For example to remove and replace a failed unit would not allow the complete system to be powered down. 6. Software Characteristics: With systems using software applications to perform their functions, such as a real-time data processing platform, it must be recognized that these, if required because of a maintenance action, to be powered down, would need time to reboot the system and retrieve any back-up configuration and database files.

27. Maintainability Modeling • Where there are specific maintainability requirements or goals, which must be obtained for a system, then there is a need to determine the system's quantitative maintainability characteristics. This could be represented in terms of a Mean-Time-To-Repair (MTTR). Other parameters to be considered are the maximum time repair and these could be determined for each of the various levels of maintenance.

28. Maintainability Modeling • The basic approach in deriving the MTTR for level one (or first line) maintenance action, would be to determine the maintenance task times for each corrective maintenance task and weight it with their occurrence. The elapse times for each corrective maintenance task could then be calculated. This would take into consideration the various steps required to implement this task and include the time to isolate the fault to the failed unit to be removed, removal time of that unit, its replace time and the time to complete system verification.

29. Maintainability Modeling • Critical to the remove and replace times is the accessibility to the failed unit required by the maintainer. This would include the ability to use the necessary hand tools and or test equipment and the actual physical removal of the unit. •   Therefore, the design phase consideration must be given to the layout of the components and avoid the prospect of having to remove other components to access a failed unit.

30. MTTR Calculation • The MTTR for a system can be calculated by using a weight factor against each corrective maintenance time (CMT), namely the unit's failure rate. The derived MTTR takes into consideration the elapse time (or CMT) required to perform the corrective maintenance tasks for each of the LRUs, making up the system. In the given formula, the MTTR represents the mean of the number of times to repair, weighted by the probability of occurrences: / Where: λ = Failure rate of the i unit MCT = Time to repair of the i unit n = Number of units

31. Maintainability Demonstration • A maintainability demonstration (M-Demo) test would be implemented to verify by demonstration the actual maintainability characteristics of a system, against the maintainability requirements or objectives. • M-Demo test would establish what criteria will be tested based upon given parameters. These would include the verification of the many maintenance tasks, which are being proposed to be implemented on a system. In the implementation of each maintenance task (corrective and preventive), all the necessary resources to permit an effective repair or maintenance activity would be assessed. This would include all supporting elements, such as the systems diagnostics capabilities, the required tools (common and special), support equipment and even the skills of the maintainer.

32. M - Demo • The M-Demo should be guided by a test plan or for smaller equipment, a test procedure; these documents would generally detail: • Test objectives: What requirements will be validated to ensure their compliance to the technical performance requirements of an equipment or system. • Test approach: How the test will be implemented and the proposed test strategy. • Ground rules: How the test will be implemented under what conditions, what the test sample size should be. This sample size maybe dedicated by the customer, for example they may require 50 failure modes to be tested, out of a candidate list of 200. Also maintenance tasks may also be required to be demonstrated under the operational conditions, to which the system will finally be fielded.

33. M - Demo • Equipment to be tested: this section would identify the equipment configuration to be tested. • Team members: These would include the key persons who will have direct involvement in the implementation of the M-Demo, and could include the test coordinator, RAM engineer and the customer. • Schedule: The schedule would detail all of the test activities including test readiness reviews (TRR), through the test implementation to the development of the test report • Data to be recorded: For the M-Demo the type of data to be collected may include the recorded maintenance task elapse times, observations made against diagnostic routines and remove and replace tasks, taken into consideration accessibility issues and required tools and human factors. • Special rules, criteria: the M-Demo may have specific criteria which must be to determined and validated. For example the witnessing of specific maintenance tasks by the customer.

34. Defect Reporting and Corrective Action System (DRACAS) • DRACAS: is a formal closed-loop reporting system that requires each reported failure to be analyzed from an maintainability perspective and if necessary, followed up with a corrective action. This system would be used in unison with the Failure Reporting And Corrective Active System (FRACAS). However, the objective of this data collection system would be to obtained specific maintainability data.