architecture for a light helicopter hums
Post on 28-Oct-2014
Embed Size (px)
DESCRIPTIONHealth and Usage Monitoring Systems (HUMS) have been shown to reduce maintenance cost while increasing availability, improving operational reliability, and enhancing safety. HUMS has been mandated in the United Kingdom on large civil transport helicopter, it was introduced as standard equipment on the Sikorsky S-92® aircraft, it is fitted on the Army’s fleet of BLACKHAWK and Apache helicopters, as well as a significant number of Navy helicopters. Despite this success, HUMS is not standard equipment on lighter helicopters and has been largely ignored as a viable retrofit option.It is commonly understood that widespread adoption of HUMS has been hampered by the incremental weight and cost of the systems. The vast majority of light helicopter owners cannot overcome the entry level weight and cost issues to take advantage of the operational and enhanced safety benefits. This paper explores a HUMS architecture that addresses the barriers to the introduction of HUMS in lighter helicopters, specifically: the reduction in hardware and installation time, the reduction in weight, and the reduction in the level of technical support (e.g. the cost of implementing a HUMS, such as threshold setting, information technology infrastructure, training) while maintaining the vast majority of HUMS functions that are currently available in current HUMS equipped fleets.
Architecture for a Light Helicopter HUMS
Eric BechhoeferNRG Systems110 Riggs Rd
Hinesburg, VT 05461
Mike AugustinIVHM Inc
6205 Glengarry CT, Ft. Worth, TX 76180
Michael KingsleySikorsky Aircraft Corporation
6900 Main StreetStratford, CT 06615
Abstract—Health and Usage Monitoring Systems (HUMS) have been shown to reduce maintenance cost while increasing availability, improving operational reliability, and enhancing safety. HUMS has been mandated in the United Kingdom on large civil transport helicopter, it was introduced as standard equipment on the Sikorsky S-92® aircraft, it is fitted on the Army’s fleet of BLACKHAWK and Apache helicopters, as well as a significant number of Navy helicopters. Despite this success, HUMS is not standard equipment on lighter helicopters and has been largely ignored as a viable retrofit option.
It is commonly understood that widespread adoption of HUMS has been hampered by the incremental weight and cost of the systems. The vast majority of light helicopter owners cannot overcome the entry level weight and cost issues to take advantage of the operational and enhanced safety benefits. This paper explores a HUMS architecture that addresses the barriers to the introduction of HUMS in lighter helicopters, specifically: the reduction in hardware and installation time, the reduction in weight, and the reduction in the level of technical support (e.g. the cost of implementing a HUMS, such as threshold setting, information technology infrastructure, training) while maintaining the vast majority of HUMS functions that are currently available in current HUMS equipped fleets.
Keywords-Health and Usage Monitoring Systems (HUMS); MEMS; Cloud Based Computing; bused sensor systems; smart sensors
The weight, cost, installation times, and in many cases the technical support costs of airborne monitoring systems supporting Health and Usage Monitoring System (HUMS) or Condition Based Maintenance (CBM) have been limited to those cases required by the regulatory agencies or justified by large fleet operations. In general the installation of the systems has also been easier to defend on larger helicopter types due to the current system cost and weight issues. For example the lightest of the helicopter vibration monitoring systems today have an installed weight of 20 or more pounds, with some weighing in at 2 to 3 times higher when including the wiring harness. The systems have been installed to provide enhanced safety and/or economic benefits. The US Army, as an example, is using the systems to derive lifecycle cost benefits such as CBM. Implementation of the systems on light and medium helicopters (aircraft weighing from 4,000 to 8,000 lbs), especially individual fleets of a few aircraft, or even a single aircraft has been limited.
Current generation systems utilize similar architectures with respect to the installation of analog sensors and point to point wiring necessitated by today’s existing technology. The intent of this paper is to review a new framework developed to provide a better value to potential users, especially to those with a few or even a single light helicopter in their fleet.
A networked architecture has been developed supporting the application configurable smart sensors in a digital bussed architecture. This new architecture along with innovative packaging, improved algorithms/processing, and simplified system operation has the potential to bring about significant improvements in installed cost and weight, return on investments, and total life cycle cost.
The aircraft system and software configuration can be automatically maintained through the systems “Cloud” based architecture. In addition, the cloud based system allows easy access to the data and the ability to leverage the results from other aircraft of the same type/model without exposure to the loss of proprietary information.
The first production lot of the Sensor Processing Modules has been produced and the system installed on a large gearbox used in a wind energy installation.
A discussion of the requirements and design considerations is included as well as a review of the data captured recently in this operational system. A helicopter system configuration is outline, addressing the most significant HUMS benefits
II. THE BUSINESS CASE FOR MONITORING
Despite the proven benefit of Health and Usage Management systems (see ,, and ), there have been relatively few deployments of systems in commercial or general aviation. Few original equipment manufacturers have offered HUMS as standard equipment for their light or even medium sized helicopters. While there are a number of aftermarket installations, the total deployed HUMS base is small compared to the number of potential installations.
The explanation for this low penetration of HUMS into medium and light helicopter market is that owners/operators cannot make the business case: the cost and weight of installing a HUMS has too much impact on their existing margins and future cash flow, potentially the weight increase alone could eliminate the use of a passenger seat. This issues and other where highlighted in . In order to achieve widespread use of HUMS in the helicopter community, both the cost and weight of HUMS must be lowered. Based on these assumptions, a
system architecture was developed with the goal of lowering cost and weight while offering primary functionality that the helicopter community has come to expect in HUMS.
Incorporating new technologies into the HUMS design that were not available even a few years ago has provided the opportunity for the reduction of cost and weight. As an example, the advent of 5th generation Microelectronic Machines Systems (MEMS) facilitates new ways to think about a HUMS system. For instance, MEMS strap-down inertial measurement units (INU) are less expensive than the cost associated with interfacing with an existing aircraft attitude, heading, reference system (cost such as customizing the software interface, adding a junction box, addition supplemental type certificate requirements, etc). In addition to the reduced cost, there is a weight savings because of the greatly reduced harnessing/junction box, connectors, etc.
Other costs borne by the consumer include an aspect of the system called “knowledge creation”. The concept encompasses the processes required to make actionable decisions based on the HUMS data. This includes:
Information technology infrastructure to host and display data,
Threshold setting for mechanical diagnostics,
Rotor Track and Balance configuration/coefficient development
Definition of exceedance parameters, and
Training of users and incorporation of HUMS into the maintenance organization/validation during the controlled service introduction.
Given the desire for lower cost and lighter weight, the system must be designed against a set of functional requirements. The ultimate goal is to design a system where the incremental cost/weight of each added function is small while the user/operator benefit is large. This philosophy defines what the functions HUMS will support.
III. SUPPORTED HUMS FUCNTIONALITY
A. Maximizing Benefits to Users
The functionality supported by HUMS is a balance between cost, weight, and customer’s needs. While there are no formal requirements for HUMS, the CAP753 (Helicopter Vibration Health Monitoring, ) gives guidance for operators on what capabilities a HUMS should support. The functionality called forth in the CAP753 is primarily concerned with Rotor Track and Balance (RTB) and Mechanical Diagnostics (MD). The document also highlights:
The need to acquire and process data in certain flight regimes,
That for flights greater than 30 minutes in stabilized conditions, a data set for all components should be automatically collected
The monitored components should include:
o Engine (Gas Generator), and the Engine to Main Gearbox input shaft(s)
o Main Gearbox (Gears, Shafts, and Bearings).o Accessory Gearbox o Tail Rotor Drive Shafto Intermediate and Tail Rotor Gearboxes
o Oil Cooler/NOTAR Circulation Control Fan
o Main Rotor (RTB, swashplate bearing wear indicators)
o Tail Rotor (RTB, swashplate bearing wear indicators)
In addition, CAP753 gives guidance on the required analyses.
Specifically, the HUMS should:
Process gear tooth indicators, which are capable of detecting gear tooth damage and tooth bending fatigue cracks,
Modulation of web tone, indicators which are capable of detecting gear web fatigue cracks and loss of gear support,
Indicators capable of monitoring planet gear load sharing and detecting planet carrier damage in the epicyclic gears
and that recording of raw data has significant value.
While the CAP753 suggests notional HUMS functionality, there are two additional functions, which for little marginal cost give acknowledged benefit to the owner/operator: Exceedance Monitoring and Flight Operations Quality Assurance (FOQA).
Exceedance Monitoring identifies, when, and for how long, a parameter threshold defined in the aircraft operations manual is exceeded. Nominally, the pilot is responsible for monitoring exceedances, but HUMS can automate the process and can give a more reliable, accurate and quantitative values for the exceedance. For example, an automated measure of an over torque can greatly simplify maintenance because there is no question as to how long and high the over torque condition existed. Other examples of exeedances include: over speeds, angle of bank/attack/flight envelops, hard landings, etc. Exceedance monitoring also provides asset protection via the monitoring of leased vehicles.
Because exceedance monitoring is, in its essence, a pattern recognition problem, the function can also automate the yellow sheet process (e.g flight time reporting requirements such as OPNAV3710/4). The exceedance monitoring algorithm can identify engine starts, taxi/flight condition, and as such, record flight time, rotor turn time, and number of takeoffs/landing.
Whereas sensors for RTB and MD must be added to the aircraft, sensors for exceedance monitoring are usually already present (e.g. via signals to the cockpit instruments) in the aircraft. Unfortunately, interfacing to these sensors from a hardware perspective can be complex, adding large recurring
cost for each installation and non-recurring engineering cost for each new platform that the HUMS is installed on.
For an analog cockpit, it requires, in addition to a number of discrete inputs, a large number of analog-to-digital converters channels. Further, it may require adding a junction box, which adds weight and cost for the installation (not to mention the costs for drawings, harnessing, etc). For a digital cockpit, while the hardware interface may be easier (e.g. Ethernet or RS-485 based data bus), the software configuration/customization could add considerable non-recurring costs.
FOQA and flight data monitoring (FDM) are fundamentally safety programs that are designed to make commercial aviation safer by providing pilot feedback and training when required regarding operational risk issues . The goal of FOQA is to identify and reduce or eliminate safety risks, as well as to minimize deviation from its regulation, through targeted training. A HUMS capability affords a relatively simple way to acquire aircraft data, since most of this type of data is needed by the exceedance monitoring function. By adding the necessary data logging provisions to HUMS, the owner/operation is provided metrics to train and improve the proficiency of its pilots.
The engineering issue for both exceedance monitoring and FOQA are how to add this functionality without the recurring and non-recurring engineering cost associated with hardware and software interfaces with existing aircraft systems.
While the four-listed functions do not encompass all possible capabilities of HUMS, it is felt that these functions are of considerable value to an owner/operator. Like any engineering problem, the delivered capability of a light weight/lower cost HUMS will be a balance of functions vs. costs.
IV. TECHNOLOGY ADVANCEMENT TO LOWER COST AND WEIGHT
It has been noted that there has been relatively little penetration of HUMS in the light or medium helicopter market. This could describe aircraft typically weighing from 4,000 to 8,000 lbs. Given the desired HUMS functionality, and this target market, one can notionally define the sensor inputs needed.
For a typical HUMS installation on this class of helicopter (Figure 1.) the vibration sensors needed to support the guidance of the CAP753 is:
Tail Rotor Radial Tail Rotor Lateral (Used for Tail Rotor
Balance and Mechanical Diagnostics) #4 Tail Rotor Drive Shaft Hanger Bearing #3 Tail Rotor Drive Shaft Hanger Bearing #2 Tail Rotor Drive Shaft Hanger Bearing Aft Oil cooler Hanger Bearing Forward Oil Cooler Hanger Bearing Engine Accessory Gear Box Input Gear Shaft Main Case, Port Side
Main Case, Starboard Side Main Case, Accessory Drive Swashplate Bearing Monitor Copilot Uni-axial Accelerometer, RTB Pilot Bi-Axial Accelerometer, RTB (e.g. two
channels)For the exceedance monitoring and FOQA functionality, a
typical system  would interface into:
Altitude and Head Reference System (AHRS) for attitude information
Vertical/Lateral Body Accelerometer Altitude and Airspeed Torque (or total engine torque) and TGT Radar Altimeter/Weight on Wheels
For a the notional light or medium helicopter, the mechanical diagnostics and RTB functionality would require 16 separate twisted pair runs throughout the aircraft. The exceedance monitoring and FOQA functions would require extensive wiring and interfacing with existing cockpit display (note that for many older aircraft or aircraft with analog cockpits, altitude and airspeed might be pneumatic. Additionally, some aircraft may not actually have some of the inputs needed to support.
Figure 1: Typical HUMS Vibration Sensor Location, Medium Helicopter
A. Reducing Cost and Weight of HUMS with MEMS
MEMS technology can provide a solution strategy to reduce both the cost and weight of HUMS. MEMS technology has been driven by commercial, hand held devices (cameras, smart phones, tablet PCs). This commercial demand has resulted in large supplier base of low cost, light (needs to fit in a cell phone) MEMS accelerometers and MEMS gyros.
As an example, the latest (5th) generation of MEMS accelerometers offers performance that in many cases is superior to traditional PZT devices if it is packaged correctly. MEMS accelerometers sense changes in capacitance, based on distance from a reference, instead of charge due to shear. Because of this physically different way to measure acceleration, these devices can measure from DC to 32 KHz. However, since MEMS accelerometers are voltage-loop devices (PZT are current looped and have better electromagnetic noise immunity), they must be packaged with an analog to digital converter (ADC) at the sensor.
Incorporating the ADC at the sensor is beneficial from both a SNR and EMI perspective. In general, sensing elements often rely on physical principles that produce very small voltages or currents. Ideally one wants to boost these small levels up as soon as possible so that the signal levels are large compared to any interference that shows up downstream. In addition, there is an EMI benefit achieved by incorporating the ADC near the preamp and transmitting (high-level) digital signals rather than (high-level) analog signals over long distances.
This requirement to package the ADC with the MEMS sensor is not a detractor to the use of the technology. In fact, it facilitates a change in the HUMS architecture paradigm by:
Enabling local processing of data at the sensor, and Developing avionic quality AHRS or Inertial
Navigation Units (INU) with the HUMS to reduce interface costs.
B. Lowering the Cost of the MD and RTB Funcitonality
The installation of the 16 accelerometers required for the notional aircraft can be modeled and the cost/weight estimated. In a conventional HUMS installation, the harnessing alone could be 10 lbs, with considerable cost in the accelerometers themselves.
Given the need to reduce cost and weight, one needs to look at how, from a system perspective, one implements design to achieve that goal. It was noted that the demand for commercial products has driven MEMS accelerometer cost down. Currently, for between 1/7 and 1/20 the cost of a high-end aviation accelerometer, one can find a MEMS accelerometer with similar performance characteristics. The reduced cost is the starting point. In making the decision to use MEMS technology, it becomes a system-engineering task to develop a suitable sensor.
As noted, the MEMS accelerometer needs to be packaged with an ADC to mitigate EMI issues. This in turn requires a microcontroller to drive the ADC, and RAM to store the sampled data. It also requires a communication receiver/transmitter. Since the sensor has a microcontroller, can the vibration data be processed locally? What type of design philosophies could be used to lower cost and facilitate reuse? These types of system level considerations are used to develop this architecture.
To reduce design time, each sensor consists of an analog board connected to a standardized digital board. The analog board contains signal conditioning (anti-aliasing filter and analog to digital converter) for the particular sensor (such as a MEMS accelerometer or tachometer interface), while the digital board has memory, a microcontroller and a receiver/transmitter for communication. This facilitates reuse (each new or future sensor type has a common digital backplane/communications).
Four sensor types were developed using this framework: low G vibration (0 to 20 Hz), high G vibration (0 to 33 KHz),
oil condition and tachometer. A structural health-monitoring sensor is under development and could be added to the architecture.
The digital backplane is designed around a microcontroller with a FPU (floating point unit), which allows all processing (vibration data for the accelerometer or zero crossing data for the tachometer) to be done locally at the sensor. Included on the digital backplane is RAM (the current design incorporates 32 MB), RS-485 for communication, and local power managements (a buck converter, which can accommodate 10 to 55 volts DC).
In this type of architecture, the tachometer sensor performs a special function of calculating the zero crossing. In most HUMS, the tachometer sensor is wired directly to the data acquisition system/computer, and the zero crossing time (ZCT) are calculated and applied to the vibration data from each accelerometer at the computer. Here the calculated zero crossing data, at the end of the acquisition, is broadcast to all sensors so that each sensor has the ability to synchronize vibration data and perform the TSA for shaft and gear analysis.
In some regards, local processing greatly simplifies signal conditioning and ESD/EMI issues. The MEMS device requires the analog to digital conversion at the sensor. This puts rigor on the packaging to provide a Faraday shield for the accelerometer. This means that there is no opportunity for the analog signal to be corrupted by EMI, or for the system to radiate.
In order to further reduce cost, an alternative to stainless steel packaging was developed. A low cost, manufacturing friendly method to encapsulate the sensor electronics was needed. This package also needs to be light and stiff to provide a good vibration transfer function to the sensor. Finally, it must be both thermally and electrically conductive. An engineered liquid crystal polymer was selected that has similar conductivity to stainless steel but only 40% of the mass. Testing of the packaged sensor demonstrated a flat transfer function from DC to greater than 17 KHz (limit of the test equipment).
Figure 2: Sensor Processing Module Vibration Sensor, 40 grams
The cost of injection molding the package (including liquid crystal polymer material) was found to be 12% the cost of traditional packaging. This coupled with the lower cost of the MEMS accelerometer (a seventh the cost of the traditional accelerometer), low cost embedded components (RAM, microcontroller, communication, signal conditioning, etc), resulted in significant cost saving over traditional systems (Figure 2, NRG Systems Sensor Processing Module). The cost for each channel is approximately 1/8 the cost of a traditional system. For further details in the system engineering of the sensor processing module, see .
The Sensor Processing Module (SPM) embedded analysis includes:
For Shaft Analysis: SO1, SO2, SO3, Time Synchronous Average (TAS) RMS, TSA Peak 2 Peak, and SO1 Phase,
For Bearing Analysis: Cage Energy, Ball Energy, Inner Race Energy, Outer Race Energy, Shaft Tick, and Average Envelope Energy for configuration envelope windows.
For Gear Analysis: Residual RMS, Residual Kurtosis, Residual P2P, Energy Ratio, Energy Operator (EO) RMS, EO P2P, FM0, Sideband Modulation Level Factor, G2, Narrow Band (NB) RMS, NB Kurtosis , Amplitude Modulation (AM) RMS, AM , Derivative AM Kurt, Frequency Modulation (FM) RMS, FM Kurt.
Each SPM can be configured to do analysis on up to 6 shafts, 9 gears, and envelope or spectrum analysis on 12 bearings. A Typical analysis time for a full sample acquisition was measured at less than 21 seconds for 40 seconds of 24 bit acquisition data sampled at 100 KHz. This means that even for short duration helicopter flights, it possible to process a full acquisition of all components in approximately 1 minute (40
second acquisition of all components, approximately 3-6 seconds to transfer ZCT to all sensors, and 21 seconds to process all the data). While raw data can be collected, most acquisition downloads processed condition indicator data for each component that was monitored, in a few seconds.
Figure 3 Bused SPM with Tach and data storage in EC2 Cloud
Additional weight saving are achieved through the use of a bused communication system. Instead of a pair of power/communication lines running to each sensor, each sensor is connected to a “T” connector on a RS-485 bus. It can be shown that, compared to a traditional PZT sensor system, the bused system is approximately 60% lighter. Figure 3 is an example of a bused vibration monitoring supporting 8 SPMs and 1 Condition Analysis Tachometer (CAT) on a utility scale wind turbine gearbox.
C. Reducing Cost and Weight of the Exceedance Montiroing and FOQA Functions with MEMS and GPS
Traditional HUMS systems interface to existing on aircraft sensors. While this give full access to most cockpit display information, it drives cost and weight into the system. Additionally, it complicates re-application cost, as it is likely that the hardware interfaces for a given platform are unique to that platform. Instead of depending on these external interfaces, consider the design impact of relying mostly on sensors dedicated to the HUMS.
The current generation of MEMS accelerometer and rate gyros have allowed the development of low cost, lightweight, strap down inertial navigation units (INUs). Other MEMS sensors, such as pressure sensors and magnetic flux sensor, will provide most of the inputs needed to support exceedance monitoring and FOQA.
Consider a HUMS INU centered on a currently available MEMS device. The package, SPI controlled unit provides a tri-axial accelerometer, tri-axial rate gyro, and a tri-axial magnetometer. Coupled with a low cost GPS receiver, a fully functioning INU with GSP update can be built at a fraction of the cost of interfacing with the existing aircraft system. Again, one of the main goals of the light weight/low cost HUMS is to reduce, as much as possible, interfaces to existing systems.
For many retrofit installations, the aircraft will not have an AHRS/INU, so that designing the HUMS with a strap down INU opens up opportunities that previously could not be supported. In fact, with only two external sensors, air speed and torque, all of the inputs required for exceedance monitoring
and FOQA could be supported. The INU with GPS update would offer: yaw, pitch, roll, vertical and lateral accelerations, heading, altitude, velocities, position, wind speed, temperature, and pressure altitude. With advanced “synthetic” sensor modeling, even gross vehicle weight could be estimated. Considered as part of the HUMS standard installation is a lower cost airspeed sensor (such as a hot wire air mass sensor for both airspeed and outside air temperature). The final installation could need only three aircraft interfaces: power, a torque and cockpit interface for BIT, and a capture data now interface (multifunction select button).
Again, to reduce cost and weight, the interface on the ground with the HUMS could be through Ethernet or 802.11 to a tablet PC for intra aircraft communication with the HUMS.
V. KNOWLEDGE CREATION AND SOFTWARE CONSIDERATIONS
Knowledge creation is the process of developing actionable maintenance events based on the information collected and displayed by HUMS. Knowledge creation is required to fully exploit HUMS: it provides indications and warnings that a maintainer can act upon such that safety and availability are improved while lowering logistic and maintenance costs. Costs include calibrating of the system and threshold setting.
There are two major software cost drivers that effect the long term ownership cost/knowledge creation of the system:
Algorithmic: this design aspect covers the digital signal processing of the vibration signals for fault detection, the organization of the data, and in general, what information is collected on the system and supports knowledge creation.
Display/User Interface: this design aspect covers the knowledge that can be displayed to the user, and cost associated with threshold setting and maintaining software.
The algorithmic design is complicated in that there is no industry accepted metric or yardstick to gauge performance. It is assumed by the operation/maintainer that when they buy a HUMS, it works as advertised. While it is absolutely the case that at some point all systems can detect a fault, the goal of a HUMS is to: detect a fault early enough to prevent collateral damage to the drivetrain and facilitate logistic support. This ability to detect a fault early drives architectural design that directly impacts performance and cost. While the CAP753 gives guidance () to ensure a basic level of performance, this does not guarantee that a HUMS can detect all faults in a timely manner.
For MD, each component in the drivetrain should be monitored as any component can cause a maintenance action with a cost and opportunity cost (e.g. lost revenue due to the helicopter being out of service). Each component has numerous fault modes. Shafts can be out of balance, cracked, bent or misaligned. Gears can have scuffing, pitting, breathing cracks, broken tooth, misalignment, eccentricity, etc. Bearing can have a bad inner race, outer race damage roller/ball element. Each component will have frequencies associated with their
geometric size and in main shaft rate. Additionally, the helicopter flight environment is subject to changing loads, which cause variation in the main shaft rate, and consequently, all of the component rates. This necessitates some methodology to normalize the vibration data (e.g. shaft rate) to a common frequency scale, so that information from one acquisition can be compared to another acquisition.
Additionally, no single CI detects all failure modes. This drives a user display requirement to view, threshold and trend information that incorporates more than just spectral data or one CI. There are numerous CIs that could be used for each shaft, gear and bearing in the gearbox. This requires a data reduction (e.g. knowledge creation) methodology that is both intuitive and user friendly. One such technique to display this information is to use the concept of a Health Indicator (HI) .
The HI allows one common numerical value to be used across all components. For example, nominal/healthy components have values between 0 and 0.5. HI values between 0.5 and 0.75 are out of tolerance, but normal. Between 0.75 and 1, components are in warning, while HI values greater than 1 are in alarm, and continued operations could cause collateral damage.
The HI paradigm reduces the cost of thresholding and facilitates data driven prognostics. Instead of thresholding individual CI values and modeling fault progression for each CI, the remaining useful life (RUL) of a component is the time until the HI is 1.0 (see ,). In figure 4, a data driven prognostic was developed using Paris’ Law to model crack propagation. The display shows the current measured HI, the filtered HI, a prognostics with RUL till warning and alarm. Perhaps most important is a bound on the prognostic performance, and measure of prognostics validity. Seen in this figure, but absent from a true system, is the true fault trajectory (see for more details).
Figure 4 Data Driven Prognostic
Fundamentally, from a display and trending perspective, the HI concept facilitates the management of a large number of data items with just one value. The HI leads to simpler maturation of HUMS. A tree view of a helicopter fleet lists the max HI values of each monitored helicopter. The user is then
able to quickly drive down to a helicopter, or a component in a helicopter (e.g. the health), then view the CI that was used in the HI calculation. While the RUL is given so that logistics can be planned, access to the CI allows the maintainer more actionable information as to the type of fault (failure mode) and severity. This knowledge creation has great value in that it allows better maintenance of the helicopter. However, most small operators lack the technical expertise to create this knowledge.
Perhaps most important, the HI ensures a constant probability of false alarm (PFA). The HUMS is designed such that the PFA is 10e-6. Then using the appropriate distributions (e.g. it is not assumed that the CI used in the HI is Gaussian. In fact, most CI distributions are non-Gaussian), the HI algorithm is developed using statistics methods (method of moments, see). The maintainer is then assured that a component with an HI of one requires maintenance. This process of threshold setting reduces the cost of application and facilitates certification as it is not an ad hoc process.
A. Other Software Costs
Large fleet operators, such as the military, can absorb information technology costs. These costs include the seat license of the HUMS database, the servers that hosts the database, and the personnel to manage and perform software maintenance. Most operators, who are more revenue conscious, can ill afford these additional recurring costs on top of the initial HUMS expense. This is especially true for smaller operators with fleets of 5 to 10 medium helicopters.
One way to reduce this cost to the customer is for the HUMS developer to host the HUMS database server in a cloud service. These commercially available web services provide scalable and secure computing capacity. This reduces the overall cost to the HUMS user by allowing the HUMS developer to effectively sell usage of the HUMS. This means that there will be a lower initial cost for the helicopter operator because they do not need to pay for the initial server, the database seat license or the personnel to maintain it.
This model is attractive to the HUMS developer for a number of reasons:
Simplifies software maintenance cost, as there is only one platform to develop and test to, and only one platform to deploy software updates/patches to,
It reduces the cost of certification, as the configuration management is greatly simplified (e.g. it is much easier to control who can install software to the cloud image)
The cloud is scalable – as more storage and computational resources are needed, it is a simple process to add resources. There is no need to buy new servers or additional software licenses.
There are a number of other attractive reasons for adopting this type of information system model. First, it allows pooling of dataset of similar type/model aircraft without risk of exposing sensitive or proprietary information. This is of great value in setting limits for exceedances, and for mechanical diagnostics. It allows for a larger population to validate the
performance of the system against nominal and faulted components. This is especially true for “finds”, as due to the nature of aviation, faults are rare (NOTE: This implies some continuing relationship between the operator and the rotorcraft OEM).
Second, it allows for a more open forum in which to recommend new features and capabilities. By pooling data from a number of users operating in different environments, users will make software/display requests, which will undoubtedly be of value to other users in the community.
Finally, as noted, the cloud offers unparalleled scalability. Even as the user base of the application grows, the cloud services provide secure, robust environment at a cost, which most operators could not match internally.
Without reducing the cost and weight of HUMS, the benefits of HUMS will not be available to light or medium helicopters or the small fleet operators that typically use them. Reducing cost and weight will require a fundamental change in HUMS architecture. Presented is a bused architecture based on MEMS accelerometer and reducing the number of aircraft interfaces as much as possible. The bused accelerometer design reduces cost and weight over current design paradigms by perhaps 60%. By internalizing aircraft state data through the use of a MEMS strapdown inertial navigation unit, both cost (non-recurring engineering/software development cost) and weight are reduced. It may be possible, through this architecture, to reduce installed system weight by 50% over the lightest available systems today.
The presented architecture is not yet available, but certain system components are. The bused MD capability has been developed and is currently deployed to monitor the gearboxes of megawatt, utility scale wind turbines. The display and reporting of the MD data is deployed on a Could service. The result has been lower cost and ease of installation (weight is not as much a concern as cost in the utility markets). Finally, a number of vendors are developing low cost strapdown INUs, which would provide most of the inputs needed to support the desired HUMS functions. It remains only a system engineering task to integrate these technologies into a HUMS and for an owner/operator or consortium to assist in providing the resources needed for the supplemental type certificate. At that point, one would expect to see the penetration of HUMS into the medium helicopter market similar to the deployment in the larger helicopter market.
 J. Wright, “Emerging Results Using IMD-HUMS in a Black Hawk Assault Battalion” American Helicopter Socieity 61st Annual Forum, Grapevine, TX, June 1-3, 2005.
 D.J.T. Siyambalapitiya, P.G. McLaren, , “Reliability improvement and economic benefits of online monitoring systems for large induction machines” IEEE Transactions on Industry Applications, Volume 26, Issue 6, 1990.
 J. Nilsson, L. Bertling,”Maintenance Management of Wind Power Systems Using Condition Monitoring Systems – Life Cycle Cost Analysis for Two Case Studies”, IEEE Transactions on Energy Conversion, Volume 22, Issue 1, 2007.
 WWEA, World Wind Energy Association, “The Benefits of a Pro-Active Approach Using Preventive and Predictive Maintenance Tools – Actual Examples and Case Studies” www.wwindea.org/technology/ch03/estructura-en.htm
 M. Augustin, “Diagnostics for Light Helicopters” IEEE Aerospace Conference, Big Sky, 2000.
 CAA, UK, “Helicopter Vibration Health Monitoring (VHM)”, CAP 753. June 2006.
 FAA, Advirosy Circular 120-82, Flight Operation Quality Assurance, December, 2004.
 E. Bechhoefer, “The Best Regime Recognition Algorithm for HUMS”, American Helicopter Society Specialist’s Meeting on Condition Based Maintenance, 2008.
 E. Bechhoefer, B. Morton, “Condition Monitoring Architecture to Reduce the Total Cost of Ownership,” IEEE PHM Conference, 2012, Denver.
 E. Bechhoefer, A. Duke, E. Mayhew, “A Case for Health Indicators vs. Condition Indicators in Mechanical Diagnostics”, American Helicopter Society Annual Forum, Virginia Beach, 2007.
 E. Bechhoefer, D. He, P. Dempsey, “Gear Health Threshold Setting Based on a Probability of False Alarm”, PHM Society Annual Forum, Montreal, 2011.
 E. Bechhoefer, S. Clark, D. He, “A State Space Model for Vibration Based Prognostics”, Annual Conference of the Prognostics and Health Management Society, 2010.
 D. Wackerly, W. Mendenhall, P. Scheaffer, Mathematical Statistics with Applications, Buxbury Press, Belmont, 19.