Abstract

One important facet of CBM+ is to formulate the assessment of the system based upon objective evaluation of degraded performance or impending failure. Only when the objective evidence substantiates the need to perform a maintenance action would the system be pulled in for maintenance. Viability and acceptance of predictive measures and appropriate metrics to ensure success have crippled efforts to add prognostic systems in the past. Only a portion of the diagnostic information is available directly from the defense system. To get the full picture requires being aware of repair activity at all levels of maintenance to correlate initial conditions to the actual root cause of the failure. This is usually the downfall of most attempts at intelligent maintenance concepts. We have typically done a horrible job of keeping track of parts in maintenance throughout the enterprise. The US Army Research, Development, and Engineering Command (RDECOM), Aviation and Missile Research, Development and Engineering Center (AMRDEC), Diagnostic/Prognostic Laboratory has developed a closed loop environment to address critical aspects of system operation, fault classification, and prognostic health management (PHM). The environment was derived from our automatic test system (ATS) improvement program to develop a closed loop system to monitor ATS performance in the field remotely and be able to provide seamless updates to the operators around the world. Recognizing that today's complex defense system data sources are diverse in their form and their context requires special attention to feature extraction and fusion to reduce potential transmission overload. Periodicity related to the sampling of data and the correlation of the data set to particular incipient fault evidence is of interest to develop a rational architecture for a systems approach to health management. In many cases we monitor individual subsystems or components and singularly diagnose failures into ambiguity groups due to insufficient discrimination of diagnostic information. Therefore we blindly wait for a failure to occur, diagnose the problem, order the appropriate part, wait for its arrival, replace the component upon arrival, test the repaired system, and put it back into operational status. This is not satisfactory any longer.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call