We’ve all heard the term “garbage in, garbage out”, and most of us are probably guilty of providing the “garbage” inputs or results sometime in our careers. Documentation is probably the single most affected area where these errors occur. <Read More>Within the maintenance community these substandard inputs have been seen with aircraft forms documentation, automated maintenance systems inputs (such as IMDS or G081), condition tags and even log books. Generations of maintainers have accomplished amazing feats troubleshooting and repairing highly complex systems ensuring mission success, but when the task was completed and the tools put away, they’d rush the documentation of the corrective action. A culture of “System broken”, “System fixed and tested” became the norm as manning constraints set in.
Now, as the new era of AI is sweeping the services along with the use of trend analysis and working toward the flightline of the future where predictive maintenance replaces preventive and reactive maintenance, the problem of decades of poor documentation has caught up with our nation’s maintenance professionals. DOD leaders have been diligently working for years to create a new maintenance and supply chain paradigm of “predictiveness”. This effort is attempting to use years of repair-chain data, that has been captured within the automated maintenance records, to front load the AI systems with the required data to produce predictive results.
With their sights firmly fixed on shifting from preventive to predictive maintenance, what can leaders do to prevent future intentional or accidental data input errors by service men and women? This is a broad topic, so let’s narrow the scope to one technology that has the capability to capture large amounts of aircraft data and information - test equipment.
For test equipment results to be useable in a predictive maintenance environment, users are normally prompted to input basic data such as aircraft tail number, equipment type, part number and serial number. Unfortunately, and more often than not, this data is input incorrectly. And, since today’s test sets that require this information have the power to capture specific failures down to the equipment or LRU, trusting the faulty information can have minor to catastrophic impacts to the aircraft and its crew.
Upon completion of the tests, the results are captured and stored on the test set in use. Of course, while useful, this data can become quite difficult to properly compile and analyze. Most maintenance units will have 2 or more of the same type of test set resulting in data stored on many separate systems, none of which import to the core automated maintenance system, and the overall repair history of the item.
Through all these complexities and possible issues preventing real-time accurate predictive maintenance, providing results for the individual equipment item or LRU, there are measures which can be taken to decrease human error and improve the overall predictive accuracy. Solutions such as IUID (Item Unique Identification) using RFID or other methods to import equipment information such as nomenclature, part number and serial number can be added on to test sets to reduce human error and achieve the stated goal of the integrated management of items. Transmitting test result data wirelessly can be accepted to consolidate test results for future analysis in real-time. This same transmission, if allowed, could be incorporated with automated maintenance systems to improve the overall repair chain information.
Using automated maintenance systems as a hub through which aircraft debrief data can be linked, and maintenance and follow-on testing can be performed, should go a long way to reduce human error or gaps in the data from the repair chain. Once the repair chain from the O-level through D-level is linked and protective measures are put in place to prevent data errors, then true predictive maintenance can begin. A day is coming when repairs can be scheduled based on future fail predictions with parts and manning availability at the optimal. At that point, maintainers will no longer be reacting to failures, but efficiently executing the maximum capability of the unit and maybe, just maybe, reducing the persistence of “garbage in, garbage out” within the services.