HUMS Long-Term Data Management

AIAC-12 Twelfth Australian International Aerospace Congress HUMS Long-Term Data Management Graham Forsyth Propulsion Systems Branch, Air Vehicles Division DSTO Australia Abstract: Many Health and Usage Monitoring Systems employ ground stations which need to preserve data for a long time, sometimes even for the full life of type, which for military platforms can be 30 years or more. Long-term data management falls into a number of areas of which three are key issues; (1) data minimisation and compression, (2) choice of most appropriate data format and (3) good data indexing to allow old data to be still useful. This paper will look at results to date of a study of these issues. Data compression can mean an algorithm to reduce the amount of data needed (and as such can be loss-less or lossy compression) but is most importantly achieved by deleting selected data (data minimisation). In the study so far, a simple data thinning arrangement has been assumed. This is simpler and less severe than the process used by many commercial systems used in motor vehicles where (a) only data on either side of an event is kept at all and (b) that data is over-written by the next event for the same event code, leaving only a list of date/times of events for each event code. Data file formats are critical to managing the data through the life of the project. A range of parameters has been defined and evaluated for a range of possible file formats. Software developed by evision for DSTO allows different weights to be assigned to each parameter and displays an overall assessment for each of the evaluated file formats. This paper demonstrates the use of this active table to match data formats to projects. 1. INTRODUCTION. Data recording is a two-edged sword. Too much data can be as big a problem as not enough what is needed, of course, is high quality information with just enough data to confirm that quality. Many vehicle monitoring systems solve this problem by having only short-term memory car systems usually record data only if an event such as an error or exceedance is noticed and keep that data only until the next event of the same type over-writes it. In aviation, monitoring has always been necessary and has become even more so with the trend to manage engines and airframes on condition. In these cases, some of the data collected needs to be retained for the life of type which is often more than 30 years and can be as many as 50 years. This paper will look at a number of steps that are being taken to examine the issues involved in longterm (i.e. more than 20 years) management of data collected by aircraft monitoring systems such as HUMS. 2. RESEARCH PROJECTS A number of current research projects relating to propulsion system monitoring and certification are looking at the HUMS data collection and management issue. These include: 2.1 The SmartHUMS research project This research project (1 4) has two aspects:- Fifth DSTO International Conference on Health & Usage Monitoring HUMS2007

a. Developing hardware, firmware and software for a prototype miniature HUMS unit in collaboration with GPS Online Solutions Pty Ltd, and b. Using the SmartHUMS prototype to investigate data collection algorithms as a PhD thesis with RMIT University. (17) This work seems to have potential, particularly in small systems and distributed systems. Further information will become available when the examiners are finished. A major feature of the approach taken is reduction in data storage. This pre-selection of data (data is only stored if an algorithm suggests a change has happened) is one technique to reduce the data management problem. 2.2 Data Validation. After collection, data need to be validated (5-8) before being used to make decisions. In practise, this validation occurs firstly as an initial assessment of collected data (by comparing with other data sources) and this assessment may be general or specific to individual data groups. The second part of this process is designed to make sure the equipment is still functioning within specification and is often performed by periodic comparison of data collected with data previously collected or being collected on other platforms. This area can become a difficult decision if major changes are made to the airborne system and/or software does one need to go right back to the validation step or simply perform only the comparison step? In general, a simple application of the comparison step should indicate if the validation step is necessary. 2.3 Data Collection Survey. Data has been collected from a number of projects. The survey looked at the amount of data expected to be collected and the amount of that data still useful at various times in the future. This survey has not been published but was used as an input into the Data Management Study. 2.4 Data Management Study. This study was conducted by two external contractors and internally at DSTO (9). The internal DSTO report identified that XML, as a substantially self-documenting format derived from SGML + was a prime candidate for long term data storage. The concept is that XML is likely to be readable across a wide range of platforms for a long time in a similar fashion to how a HTML file can be displayed across almost any platform that supports an appropriate browser. Of course, there are some differences between HTML and XML, particularly in the treatment of errors and missing information. A single well-designed XML browser should be able to read XML files from all HUMS GSE in the same fashion that a web browser reads all well-designed webpages. The two contractors (10,11) were asked for possible solutions of a specific problem based on expected data volumes and retention requirements. Actual media types were not studied deeply it was felt that all data needed to be re-written to the latest media regularly, at least at each major upgrade to ground support equipment (GSE). For a typical military situation, it was felt that the airborne or on-vehicle data collection system may only be upgraded once or twice in a 25 to 30 year lifespan but the GSE would be upgraded probably twice as often. The evision report (10) identified a range of possible file formats and identified a list for further study. These were direct data files with data stored as binary, text (comma or tab delimited) or XML format, Commercial Off The Shelf (COTS) databases and Open Source Databases. The database options could have binary records, structured records, XML records, or binary records with reports producing external XML files. Each of these data format options was assessed against each of a list of standard extensible Markup Language relates to information in a similar way to the relation of HyperText Markup Language (HTML) used on webpages to plain text. + Standardised Graphical Markup Language was defined in the 1980s for documenting information in a defined way. HTML and XML are specific implementations. 2

attributes. These standard attributes included features such as file size, processing capability, ease of data format changes, file robustness, expected readability in 30 years, data security, ease of conversion to other formats and cost of implementation. 2.4.1 Data Format Selection Table A software version of the summary table in the evision report (10) has also been produced (12). The software is a single active page viewable using any modern web browser and the following Figure shows the initial display of that software. Figure 1. Default View for HUMS Software Data Format Table Eleven of the file formats mentioned are displayed across the screen. The user may click on any of those columns to hide that rejected format and may otherwise customise the display. Simply placing the cursor above items on this table displays help text. As an example, the following figure shows three such help text windows; in practise of course only one would be visible at a time. Help text is available for all the major features of the table, not just these three. Figure 2. Default View plus three examples of help text 3

The user has the option to modify the importance placed on each of the parameters corresponding to the list of standard attributes mentioned above., by adjusting the weight against each while keeping the total at 1000 points or 100%. The following Figures show that process partway through and after completion. In these examples, the importance of data readability and data security have been increased at the expense of ease of conversion and file size. Such a change would indicate a project where data security was likely to be a greater issue and the data was less likely to be needed outside the GSE itself. At present, this software table is regarded as an interesting outcome of this work. (13) Figure 3. Part way through modifying the Importance scores Figure 4. After Completing modifying the Importance scores 2.5 Data Usefulness. This study (14-15) has been partly completed for a specific implementation for the MRH90 helicopter. The concept is to look at areas were the data collected may have additional uses and postulate specific questions which may be answered using such data. Because the data acquired by HUMS varies from platform to platform and because additional uses to which that data could be put are also platform 4

dependent, it appears that a separate study on this topic may be necessary for all new installations, at least until standards become more developed. The final results of the study will be available during 2008 or early 2009. 2.6 Data Verification and Certification Aspects. Data Verification and Certification (16) are two distinct aspects of ensuring that HUMS data are valid. Data verification normally implies a two-part process: (1) an initial validation of the data actually being collected against either an independent data source or against another validated collector and (2) a data screening routine which seeks to identify data errors developing during use. On the other hand, certification implies a defined, documented process to manage the HUMS, the HUMS software and the HUMS data. Of interest as regards certification is the implication of the increasingly common engine certifications which require on-condition maintenance and hence valid HUMS data. DSTO are increasingly being asked for advice as regards both of these aspects. The current trend is that both engines and HUMS certified overseas are needing less work to ensure that the overseas certification applies here and hopefully this will continue.. For every HUMS and related GSE an initial data validation is essential along with care to ensure that the GSE process is likely to trap developing errors. 3. HUMS DATA LIFE CYCLE A different way to look at the HUMS Data Management problem is to consider the data life cycle in terms of steps through a long process. The following Table shows where the work described above fits in such a life cycle. Step Action Project 1 Minimise Data Collection SmartHUMS 2 Data Collection Acquisition Proposals 3 Data Validation Most Acquisitions 4 HUMS/Engine Certification Most Acquisitions 5 Additional Uses Data Usefulness Studies 6 Compress Data Data Management Study 7 Data storage format Data Management Study 8 Data thinning Data Collection Survey 9 Data Re-writing at new GSE Data Management Study 10 Additional Uses for Withdrawal Not yet studied Table 1: HUMS Data Life Cycle It is believed that HUMS data may have additional uses during the final part of a fleet life of type but Australia, like most military operators, has no HUMS equipped aircraft close to the life of type so this issue has not received attention yet. However, it is extremely likely that the prognostic and diagnostic features of HUMS could safely extend the life of some specific platforms. 4. CONCLUSION. The first conclusion from this study is simply that unwanted data are also unnecessary - only record that data which has a defined purpose and a scheme to use it. Of course, that does not mean that extra or spare parameters cannot be added to the parameter list but that such parameters must have a defined purpose even if only a backup to another parameter. Secondly, data should not outlive its usefulness. On the other hand, data may have additional use, particularly towards the end of the life of type and to supplement other data sources in particular situations. An example could be using both Flight Data Recorder and HUMS information together. 5

Thirdly, data needs to be moved to new media and re-checked at regular times. The suggestion is at every update to the Ground Support Equipment. Data management is probably the least standardised part of current HUMS. Future expectations are for most HUMS data to be stored in XML databases or extracted from databases in XML format. This will eventually allow a single HUMS XML browser to work with all such HUMS data repositories in the same way a web browser reads all well designed webpages. 6

REFERENCES. 1. Detection Indices for a Miniaturised Health and Usage Monitoring System Unit, Eric C.J. Lee and Graham F Forsyth, DSTO and Cees Bil, RMIT University, in Proceedings of 24th Congress of the International Council of the Aeronautical Sciences, 29th August - 3rd September 2004, Yokohama Japan. 2. Method to Compare Autocorrelation Results Obtained Using a SmartHUMS Unit, Eric C.J. Lee and Graham F Forsyth, DSTO and Cees Bil, RMIT University, in Proceedings of Eleventh Australian International Aerospace Congress, Melbourne, March 2005. 3. Using Detection Indices (DIs) to Detect Air Vehicle Characteristic Changes for HUMS Application, Eric C.J. Lee and Graham F Forsyth, DSTO and Cees Bil, RMIT University, ICAS 2006-9.8.3 in Proceedings of 25th Congress of International Council of the Aeronautical Sciences (ICAS 2006), Hamburg Germany, September 2006. 4. A Low Cost Approach to Helicopter Health and Usage Monitoring, Eric C.J. Lee and Graham F Forsyth, DSTO and Cees Bil, RMIT University, Proceedings of 32 nd European Rotorcraft Forum (ERF 2006), Maastricht, The Netherlands, November 2006. 5. C-130J-30 in-flight Propeller Balancing, Brian Rebbechi, Paul Marsden and Ken Vaughan, DSTO, in Proceedings of Eleventh Australian International Aerospace Congress, Melbourne, March 2005. 6. The Validation of HUMS Engine Data, Joanna Kappas, DSTO, in Proceedings of Eleventh Australian International Aerospace Congress, Melbourne, March 2005. 7. Validation of C-130J-30 Engine Monitoring System Data, Joanna Kappas, DSTO-TR-1732, June 2005. 8. Weight Split Algorithm for Propeller Balancing, P.R. Marsden, Air Vehicles Division Defence Science and Technology Organisation, DSTO TN 0661, January 2006. [Limited Release.] 9. Case for XML as the Format for Long-term Storage of HUMS Data, Graham F Forsyth, DSTO, in Proceedings of Eleventh Australian International Aerospace Congress, Melbourne, March 2005. 10. DSTO Contractor Report: HUMS Data Management Study for application to JSF Data: Phase 1 and Participant 1, by G.F. Forsyth, Air Vehicles Division DSTO Melbourne and Philip Joyce, evision Pty Ltd, May 2005. [Limited Release.] 11. Engine and Aircraft Health and Usage Monitoring Systems Data Management Study, J Gloster, QINETIQ/D&TS/AIR/CR052759, June 2005. [Limited Release.] 12. DSTO Contractor Report: HUMS Data Management Study for application to JSF Data: Software Model of HUMS Data Format Options Table, by G.F. Forsyth Air Vehicles Division DSTO Melbourne and Philip Joyce, evision Pty Ltd, March 2006. [Limited Release.] 13. Data Management A Missing Part of the HUMS Program, Graham Forsyth, DSTO Australia, Presentation to Defence College of Management and Technology (DCMT) Symposium on HUMS (HUMS 06), Shrivenham, UK, May 2006. 14. MRH-90 HUMS Data Gathering for Fleet Usage Aspects - Phase 1, Kamal Gill, Aerostructures, June 2006 [Commercial-in-Confidence, Limited Release.] 15. MRH-90 HUMS Data Gathering for Accident/Incident Investigation Aspects - Phase 1, Kamal Gill, Aerostructures, June 2006 [Commercial-in-Confidence, Limited Release.] 16. Certification of HUMS for Propeller Balance, Engine Health and Engine Life Usage, Graham Forsyth, Air Vehicles Division, DSTO Australia, presented by Dr Rod Barnes, Attaché Defence Science, Embassy of Australia, Washington to Helitune 2005 User Conference, Duck North Carolina, October 2005. 17. PhD Thesis, Eric Lee, passed to RMIT University examiners January 2007. [Details not available until published.] 7