HOT Logistic Support Analysis

Transcription

1 HOT Logistic Support Analysis C Taljaard R&M Technologies CC Mobile: +27 (0) Copyright 2013 by C Taljaard. Published and used by INCOSE SA with permission Abstract: The logistic support analysis, failure mode effects and criticality analysis (FMECA), support modeling, and reliability-centered maintenance (RCM) are activities to optimize the maintenance and support of a system. Few companies have successfully implemented a feedback system and are able to measure system reliability, availability and maintenance performance characteristics. This paper discusses the use of a failure recording analysis and corrective action system (FRACAS) logistic support analysis database and model-based analysis as a forerunner to improve the LSA data. It also discusses implementation problems and some recommendation to improve the LSA information throughout the systems life cycle. Introduction and Theory The logistic support analysis ( LSA), also known as supportability analysis, is a designed analysis process and is part of the overall systems engineering analysis effort. The functional breakdown structure, system definition, system specification and the support & maintenance concept provide the starting point for the analysis. The analysis includes techniques such as failure mode, effects and criticality analysis (FMECA), fault tree analysis (FTA), detail task analysis (DTA), reliability-centered maintenance (RCM), level of repair analysis (LORA) and life-cycle cost analysis (LCCA). The LSA is a process during which the logistic support requirements for a system are identified and evaluated. The analysis and techniques are used to: identify the supportability requirements as an input to design evaluate the various design options identify and acquire the various elements of maintenance & support and access & improve the system support throughout the system s life cycle The logistic support analysis is an iterative process which increases in detail as the design matures. The data from the LSA is documented and captured into a logistic support analysis database (LSA database).

2 Figure 1: Logistic Support Analysis Process. The LSA process can generally be describe in the following phases: Phase A: System definition: (what does the equipment consist of?) The breakdown structure of a system should be developed to assist in identifying the items in the system. This breakdown structure forms the baseline at various stages and it should be continuously updated and refined to the required level of detail. Phase B: Failure analysis: (how can the item fail and if so how critical are the failure?) The breakdown structure is used to perform a FMECA, with the main objective to identify all maintenance tasks for potential failure modes. The criticalities of failure modes are used to prioritise corrective and preventive maintenance task. Phase C: Task identification and optimization: (what corrective and preventative, maintenance must be performed?) Corrective maintenance tasks are identified using FMECA, while preventive maintenance tasks are identified using RCM. Trade-off studies may be required to achieve an optimized maintenance strategy. Phase D: Detail task analysis: (what resources will be used for the task i.e. personnel support equipment and facilities?) Detail procedures for corrective and preventive maintenance tasks should be developed as inputs to the technical publications. Support resources are identified and allocated to each task which should include personnel, support equipment, spare part and facility requirements. A level of repair analysis (LORA) may be performed to determine the most cost effective organization for executing these tasks.

3 Central to the logistic support analysis is the FMECA, which is a postulation of potential failure modes. These failure modes are linked to tasks to determine a task list of corrective and preventive maintenance tasks. The task list is used for further analysis of the task requirements and task descriptions. It is important to note that the identification of the failure modes is only a postulation which depends on the ability and experience of the logistic engineer and to understand the system, it s operational and maintenance environment. Figure 2: Failure Mode Relationships and Dependency Failure modes are also central to support & reliability, availability and maintainability (RAM) modeling activities. These activities are also used to determine key performance indicators (KPI) to measure an improved system performance. The detection means, a column from the FMECA and the fault tree analysis is also used to identify built-in test and condition monitoring requirements.

4 Practical Implementation Problems The LSA database (historically known as the logistic support analysis records - LSAR) has implementation problems. It is often not implemented in the commercial sector and in the military, only implemented if funds are available. Reliability-centered maintenance (RCM), or variants of it, is accepted in the aircraft and industrial sector but is criticized as a timeconsuming process with implementation difficulties. Operational baseline wall: The system and its support are defined during the developments stages. The support database, at the end of the development stage, contains a postulation of what can fail and what we must be done to repair or prevent a failure. The data is sometimes used as an operational baseline and imported into a user maintenance management system. Once imported and thrown over the wall, the database remains static with little or no updates during the operational and support stages. Very few if any, processes exist to capture the knowledge gained from the operational and support stages into the LSA database. Figure 3: Baseline and Documentation Wall The support database at the end of the development stages is therefore: a postulation which is not a true reflection of the reality and it will remain in this format for the entire lifecycle. Addition to this: a system may not be used as intended and leads to an increased distance to reality.

5 The documentation wall: Systems engineering includes various disciplines and the logistic engineer is responsible for execution of the logistic support analysis. It is his responsibility to identify the maintenance task and the skills required to perform the task. The technical author is responsible to document the task procedure into technical publications (documentation) and the instructional designer is responsible to develop the training and training material. In practice, these disciplines are working in different silos and in isolation. A task list produced by the logistic engineer is a one directional output to the documentation process for further development. When developed, the documentation and LSA processes follow separate review paths. It is common that changes in the maintenance philosophy are implemented in the documentation, without been implemented in the LSA database. The LSA, documentation and training process is also a sequential process and all these activities must be complete at the end of the development stage. Timescale imitations at the end of the project do not allow for the sequential execution and it promotes a simultaneous execution of these activities with separate results. The documentation wall leads to a fragmented support system and it often ends up with clumsy documentation, containing unnecessary information. It also leads to a LSA database which does not support the documentation. The wonderland of modeling: Modeling the support, availability and life cycle cost of a system during the design stages is based on statistics. These statistics are hardly available and to predict MTBF s is very difficult, if not impossible. Most models are based on modeling the exponential distribution and the parameters are often not known or fully understood. Modeling reports are developed during the development phase and the logic is not fully captured to allow a repeatable re-run of the model at a later stage. The contents and outcome of the model depends on the capability of the person and the software used (modeling the flavor of the month). Measuring what we can: Without a clear understanding of where & what parameters to measure, engineers decides to measures all possible parameters. This leads to the measurement of parameters which are not required and with no action plan. A clear understanding and a scientific method is required to determine which parameters to measure. An action plan must also be developed to define and stipulate the actions if these measurements are out-off bounds. This measurement philosophy may also chance as the system is used depending on the requirements and operational environment. The philosophy and action plan required today may not be relevant tomorrow.

6 Discussion Continue improvement: The LSA database should be used, by the original equipment manufacturer, as a knowledge base, to improve the support of a system. This database contains valuable support requirement relationships and must continually be improved through-out the entire lifecycle of the system. New technologies enable us to promptly update the LSA database, with actual failure modes and tasks data from the maintenance tasks performed. It enables us to integrate a failure recording analysis and corrective action system (FRACAS) with the LSA process. Figure 4: Continues Improvement Modeling and database integration: An integrated approach is required to ensure that the same data are used and the modeling logic is consistent throughout the life cycle. Consistency can be achieved by including the reliability block diagram and fault tree diagrams in the LSA database. A deploy & support model and operational model must also be included in the database and must constantly be updated to accommodate any changes in the environment. Using an integrated LSA database, modeling approach has the following advantages: Updating and refining the model, shorten the modeling cycle and the knowledge is transferred from generation to generation It uses the same data set for the modeling as defined in the LSA database It encourages constancy in the assumptions Capture the modeling algoritms and approach It encourages the re-use of the model as better information becomes available Use the LSA database as a knowledge base for modeling future projects It verifies the LSA data during the design stages

7 Figure 5: HOT LSA Documentation and database integration: It is important to fully integrate the LSA and the documentation development process. Any changes in the documentation must be initiated by updating the LSA data. Feedback from the operational use and failure data recording is required to improve the LSA and the documentation. Figure 6: Documentation and LSA Integration

8 The organization responsible to for the documentation must also be the organization responsible to keep the LSA updated. An integrated LSA and documentation process contain the following phases (also see Figure 1 and 6): Phase A: System definition Phase B: Failure analysis Phase C: Task identification Phase D1: Identify the support requirements Phase D2: Identify the data module requirements list (DMRL for electronic technical publications) Phase D3: Develop the illustrated parts breakdown (IPB) Phase D4: Provide data module editing and authoring capability (for electronic technical publications) Phase E: Operational use and failure data recording A common source database could also be use depending on the requirement of the project or organization. Through life optimization modeling: Support and RAM models can be classified into two (2) types of models: 1) A decision model is a model which is required to assist in making a decision during a specific stage of development. A decision model has momentarily value and the results are implemented and documented in a modeling report. Examples of these models are level of repair analysis and spare part models to determine the requirement at a specific time. 2) A through life optimization model, is a model which is required to determine system KPIs ( key performance indicators). It is used to optimize the system throughout the entire life cycle of the system and examples are availability, and cost models. Figure 7: Through Life Optimisation Modeling The development of a reliability block diagram (RBD) and/or fault tree analysis (FTA) diagram is a pre-requisite to the measurement of optimization parameters. It defines the

9 availability and guides the measurement to set-up an availability monitoring system (availability dashboard). Failure mode and condition monitoring: Parameters can be classified as parameters to determine equipment status, condition or operating durations. Availability status and failure identification parameters are measured to determine the availability and failure condition respectively. Figure 8: Parameter Measurement Reliability analysis, the FMECA, RBD and FTA s can be used to determine what parameters must be measured during the operational stage. Electronic measurement can be performed by integrating the failure recording system with health and monitoring systems (HUMS, SCADA and BMS building management systems). It is important to develop and document the parameter measurement strategy in the LSA database as part of the FMECA, RBD and FTA process. Documentation and FRACAS integration (Through life support): The failure data must be analysis to determine the failure mode and tasks performed. The failure and task data can be recorded using the physical structure, illustrated parts breakdown and the technical documentation from the LSA database. The failure modes and tasks from the LSA is preloaded and used as a selection when recording the actual modes and task. Failure modes and task can be selected or added if not available (blue items are additional items not identified during the initial LSA).

10 Figure 9: Electronic Documentation, FRACAS and Through Life Support Figure 10: Failure & Task Recording

11 Summary and Conclusion The logistic support analysis results, is documented in a database and contains valuable failure mode, task and task requirements data. The LSA is subjective and must evolve into more detail as knowledge is obtained on the system failures, it s operating and support environment. The following conclusions can be made: The LSA and database is critical to the quality of the support documentation of a system. The LSA and database is critical to provide a coherent support solution. An OEM's should use the LSA database to continually improve the support of the system (through life support). The database should be used as a corporate memory to enhance the quality of future projects. Through life optimization modeling should form part of the LSA database. The LSA database is an integrated part of the documentation development and update process. The condition monitoring strategy is also part of the LSA database ( FMECA, RBD and FTA process). Modeling and failure data recording should be used to verify and validate the LSA data throughout the entire lifecycle of a system. References [1] B.S. Blanchard, Logistics Engineering and Management, 6th edition, Pearson Prentice Hall, 2004 [2] James V Jones, Integrated Logistics Support Handbook, 01 Jan 2006 Biography Corrie commenced employment in 1979 at the Armscor Quality Engineering Laboratory. Since 1983, he has specialized in reliability and maintainability engineering and was responsible for the management and execution of these activities on a number of major projects. A number of technical papers on these topics were also presented at various national symposia. In 1990 he co-found R&M Technologies, where he is currently responsible for reliability-centered maintenance, availability modeling, maintenance optimization and condition monitoring. He is currently providing consulting services relating to the development of a maintenance, logistic support and failure recording system (FRACAS) for the Square Kilometer Array (SKA) telescope. In 1985 he was certified as a quality engineer by the American Society for Quality Control and in 2000 he received a B.Sc. (Hons) degree from the University of Pretoria.