This item was submitted to Loughborough’s Institutional Repository (https://dspace.lboro.ac.uk/) by the author and is made available under the following Creative Commons Licence conditions. For the full text of this licence, please go to: http://creativecommons.org/licenses/by-nc-nd/2.5/ 2010 5th International Conference on System of Systems Engineering SYSTEMS APPROACH FOR HEALTH MANAGEMENT DESIGN: A SIMPLE FUEL SYSTEM CASE STUDY Mandeep Khella1,2, Tony Martin2, John Pearson2 and Roger Dixon1 1 Electronic and Electrical Engineering Dept, Loughborough University, Leicestershire, LE11 3TU, UK 2 Systems Engineering Innovation Centre, Loughborough University, Leicestershire, LE11 3TU, UK Abstract – This paper presents the first of two case studies conducted in 2009, to evaluate a concept for specifying and designing a Health Management System (HMS). This first case study made use of a representative Unmanned Aerial Vehicle fuel system. Conflicting information requirements relating to the health of the fuel system were defined for a given stakeholder (Fuel System Maintenance Engineer). Following a Failure Modes and Effects Analysis of the fuel system, the concept was applied under two scenarios (with and without additional sensors), to specify associated HMS designs. These two designs were then compared to consider how well each design addressed the conflicting requirements. In addition, attributes such as weight, cost and power were also associated to the underlying HMS sensors. The attribute values were aggregated to the requirements level and demonstrated a new approach to designing and evaluating alternative HMS designs. The case study demonstrated that although this was a simple evaluation, the underlying concept has shown considerable potential in supporting a holistic approach to designing HMSs and supports informed trade-off analysis and design decision making. Index Terms—Availability Contracting, Health Management System, Line Replaceable Unit (LRU), Maintenance. I. INTRODUCTION The inception of availability based contracting has seen significant changes in many industrial sectors. Taking the example of military aircraft, governments are driving changes in the defence sector given the increase in the total cost of ownership of these platforms, reducing defence budgets and the need for a flexible force projection capability [1]. For example, the UK Ministry of Defence (MoD) spent £9 billion on support contracts with industry in 2004/5 [1]. This represents a significant proportion of the MoD’s external expenditure. Consequently the MoD issued the Defence Industrial Strategy (DIS) in December 2005 outlining their requirements to industry for close partnering and increased availability based, product-service package offerings such as the Tornado ATTACK program [1]. Such an offering transfers risk in the total cost of ownership of assets from the customer to the supplier. Both the UK MoD [2] and the US Department of Defense (DoD) [3] continue driving requirements to industry supporting a move towards availability based contracting. However this transformation requires changes within both the customer and supplier organisations including changes in the ownership and management of the supply chain. Although significant progress has been made to this end, further transformation continues and the MoD expects to issue an update to the DIS to reflect this progress and the future direction. Consider the civil aircraft sector, where Rolls Royce (RR) offers a Total-Care Package for their gas turbine engines. This matured product-service package offers through life management of gas turbines where again cost of ownership associated risk is transferred to the manufacturer/supplier [4], [5]. Product-service based availability contracting does offer a substantial return on investment opportunity to industry. You 978-1-4244-8196-5/10/$26.00 ©2010 IEEE DOI 10.1109/SOSE.2010.421 only have to consider the sum spent by the MoD on support contracts to gauge the scale of the support market both in civil and defense. However industry will need to drive efficiency improvements on support and maintenance regimes to leverage maximum return on such contracts. Companies such as RR are taking advantage of this emerging market. They have invested heavily in establishing a global support network for their civil aerospace gas turbine market. More subtle yet significant, is their matured understanding of their products, the operating environment and the end user (in this case the airline pilot). This combined understanding can drive changes from operator training to placement of sensors on the product to collect health data, all to increase the reliability of the engine whilst enabling a move towards condition based maintenance rather than a fixed calendar based support regime. Consequently interest in health management technologies has increased across various industrial sectors. Health Management Systems (HMS) are used to collect data from platforms which can be a combination of on-board or offboard systems. HMS can be developed for new or legacy platforms. In either case, the key enabler for reducing support costs is the collection and timely analysis of the correct data. Given the obvious danger of incorrect sensor placement, collecting incorrect data and even large quantities of data which are never analysed due to lack of resource, there is a challenge in specifying and designing an HMS. II. HMS DESIGN CONCEPT The market for software tools to assist in the design and specification of HMSs is expanding given the increase in the product-service oriented market across many sectors. Reference [6] presents a list of available tools relevant to developing HMSs. The analysis of these tools identified a gap whereby the underlying HMS sensors and derived data and information are not necessarily related directly to stakeholders who will utilise the health information. Reference [6] outlines a concept for a tool to fill this gap underpinned by general Systems Engineering principles allowing it to be applied to a wide range of platforms. Although a detailed description of the concept is presented in [6], a brief overview is presented here. The concept is developed around a graphical approach to organising information relevant to the design of an HMS in layers as illustrated in Fig. 1. Fig. 1 shows the relevant information classed in two groups. The first covers the human or soft aspects of the design involving identification of stakeholders and their associated information requirements related to the health of a Platform of Interest (PoI). The requirements are decomposed in to data requirements to complete this set of “soft” data. A. System Scoping The case study was scoped to utilise a representative fuel system based on a typical civil UAV. The fuel system was identified as the candidate system for this case study, given the availability of the Advanced Diagnostic Test Facility (ADTF) located at the Systems Engineering Innovation Centre (SEIC) at Loughborough University. The ADTF was used to model the fuel system and validate the proposed HMS design from the case study on real software and hardware. Reference [8] describes the ADTF and a fuel system configuration which has been modified for this research. The modified fuel system configuration is shown in Fig. 2. The modification from the fuel system shown in [8] is that only one fuel pump was used per fuel tank. This is depicted in Fig. 2. through the marked out fuel pumps. Therefore the system shown consists of three fuel tanks each consisting of a fuel gauge probe to determine fuel quantities and flow rates from the tanks. One tank acts as the collector tank and feeds fuel to the engine through a boost pump and engine fuel feed line. The fuel feed line has a seal (not shown) and pressure switch near the boost pump which cuts power to the pump if a low pressure threshold is tripped. The fuel feed line also has a flow sensor near the engine. Fig. 1. Fundamental Tool Concept The second group represented by the lower three layers can be referred to as the “hardware” comprising of the PoI breakdown which can involve a detailed view of sub-systems and their component layout, the types of sensors available or planned for installation on the PoI and finally the data transformations required to fuse the raw sensor data to meaningful data and information as identified from the stakeholder requirements. The data transformation level represents the core layer of the concept, as it is this layer which defines the algorithms used to generate useful data and information which, depending on the algorithms, may be used for diagnostics (detecting and isolating faults) or even prognostics (predicting failures). This level would be ‘designed’ by an engineer to allow specification of an HMS. It is expected that by developing and filling in the layers of the concept, given a particular PoI, the engineer will be specifying the HMS required to meet the information requirements of the stakeholders. III. CONCEPT CASE STUDY – FUEL SYSTEM Evaluation of the concept proposed in [6] has been undertaken through two independent case studies completed in 2009. The case studies involved an Unmanned Aerial Vehicle (UAV) Fuel System and the Neutral Beam System on the Joint European Torus (JET) Fusion experiment [7]. This paper describes the first of these two case studies. Fig. 2. ADTF Fuel System Configuration The case study considered several relevant stakeholders with an interest in the health of the given fuel system, such as the pilot/operator, maintenance engineer and fleet manager. Whilst the case study only considered the fuel system, the range of stakeholders provided a number of complex interacting requirements. However for clarity of presentation, this paper only considers the maintenance engineer. Two stakeholder level requirements related to the maintenance engineer were considered in the case study. The first was concerned with improving the availability of the UAV platform through reduced downtime and unplanned maintenance. The second requirement was concerned with reducing the unnecessary replacement of Line Replaceable Units (LRU) on the UAV, referred to as No Fault Found (NFF) occurrences. These requirements were defined as follows: x x Develop an HMS that shall improve the availability of the UAV. Develop an HMS that shall reduce the number of No Fault Found (NFF) occurrences on the UAV. These and subsequent derived requirements were not complete requirements as, for example, they did not quantify the required level of availability or the number by which to reduce the NFF occurrences. They were however defined to a sufficient level of detail to support evaluation of the concept. They were also considered in the context of the in-scope fuel system only, excluding the wider UAV vehicle systems. The above two requirements were chosen for their conflicting nature to show the value of the Systems Engineering approach embedded within the concept for resolving them. The conflict in these requirements manifests itself in the maintenance engineer removing several potentially faulty components from the fuel system without further fault finding and isolation, in an attempt to reduce the downtime and increase the UAV’s operational availability. This can result in several of the components returning from the manufacturers’ repair facility with no fault found, unnecessarily expending support budget and reducing the number of LRU available to hand at the maintenance facility. Alternatively to correctly detected and isolate the failure down to the actual component, the maintenance engineer may require a longer maintenance period, reducing the availability of the UAV. Considering only the fuel system, the following data requirement was derived from the top level requirements to limit the scope of the case study: x failure symptoms the maintenance engineer would be interested in detecting and isolating. This task was fulfilled through performing a Failure Modes and Effects Analysis (FMEA) of the given fuel system. The analysis was simplified as failures were only considered between the Collector tank pump to the engine feed line interface to the engine. This involved four components, namely, the fuel pump, pump pressure switch, seal and fuel feed line. The FMEA showed that the presence or absence of four System Level Failure Symptoms was required to isolate engine fuel feed failures down to one component. These four failure symptoms were: x x x x Restricted fuel flow to the engine Loss of fuel from the system Low engine feed line inlet pressure High engine feed line inlet pressure The output from the analysis is captured in the FMEA extract in Table 1. TABLE I Component Local Effect Pump No power Pressure Switch Pipe *No pressure signal Low pressure signal Blockage Seal Split System Level Symptom Restricted fuel flow to engine Low engine feed line pressure Restricted fuel flow to engine Low engine feed line pressure Restricted fuel flow to engine High engine feed line pressure Restricted fuel flow to engine Loss of fuel from system Low engine feed line pressure *The pressure switch is only used to cut power to the pump in the event of a low pressure in the engine fuel feed line. Therefore the failure mode concerning no signal from the pressure switch was ignored. The above information is presented in Fig. 3 as a component and symptom mapping to show the level of interactions in even a simple system as this. The HMS shall determine the health of the critical fuel system functions. Although several critical fuel system functions would exist that are of interest to the maintenance engineer, only the following was considered during the case study: x The HMS shall isolate engine fuel feed failures to “x” LRUs. The “x” in the above data requirement refers to a specific number of LRUs. This has been quantified in each of the case studies under Section IV. Trial & Analysis. The information defined above was sufficient for the completion of the stakeholder, information and data requirements, systems and sensor layers of the concept as described in Fig. 1. However the data requirement above required further decomposition to articulate exactly which Fig. 3. Component – Symptom Relationship IV. TRIAL & ANALYSIS The case study involved two analyses. The first was a bottom-up analysis taking the platform available sensors. The second used a top down view through considering the stakeholder requirements to diagnose faults down to one LRU and define the required sensor suite for the fuel system. A. Case 1 – 1/3 LRUs The first case study considered the problem from the platforms’ perspective considering only the available sensors. This would show what level of HMS could be developed with minimal modifications to the UAV. Fig. 4 shows the output from applying the concept by considering only the available sensors to meet the stakeholder requirements. The HMS design logic is as below. Restricted fuel flow to the engine can be detected by comparing the actual flow to the engine using the existing flow sensor in the feed line and the expected fuel flow based on the engine throttle demand. This analysis utilises the existing fuel flow sensor. Similarly, loss of fuel from the system can be detected by comparing the change in the fuel level in the fuel tanks using the gauge probes against the fuel flowing to the engine. A difference here (identified with appropriate thresholds to account for sensor noise and inaccuracies) can be used to identify loss of fuel from the aircraft. This analysis utilises the existing fuel level sensors. of interest. This view point of the maintenance engineer would help to determine the required HMS to isolate engine feed failures down to one component. The resulting analysis and HMS design is shown in Fig. 5. The HMS design logic is as follows: Restricted fuel flow to the engine and loss of fuel from the system are as described in Fig. 4. Additionally in order to detect low and high engine feed line inlet pressure, a new sensor is required. A pressure sensor reading in the fuel feed line can be compared to the required pressure based on the engine throttle demand. Negative or positive differences can be used to detect low or high pressure occurrences. Fig. 5. Stakeholder Requirement Perspective (Top-down) Fig. 4. Platform Sensors Perspective (Bottom-up) In this case the HMS cannot detect low and high engine feed line inlet pressures. The resulting impact, analysed through the fuel system FMEA implies that the proposed HMS can indicate to the maintenance engineer the isolation of engine fuel feed failures down to one component in the event of a leak (split seal) but would not be able to differentiate between the remaining three components in the event of one of them failing. Therefore additional effort would be required on the ground to further isolate the failed component or up to three components may be replaced in an attempt to reduce maintenance down time. However two of the three components may be found to have no fault (NFF). B. Case 2 – 1 LRU The concept was applied again using the maintenance engineers’ requirement as the starting point to develop a simple HMS solution capable of detecting all four symptoms In this case the additional information can be used to detect a pipe blockage (given a high engine feed line pressure). Furthermore the pressure reading from the sensor can be compared to the pressure switch to determine if it has failed low given a throttle demand is present. Finally normal values between the pressure sensor and switch would indicate a problem with the pump given a low flow is present. In this way the addition of a single sensor has provided the level of fault resolution necessary to meet the stakeholder requirement. The HMS design offered in Fig. 5 is able to resolve the conflicting maintenance stakeholder requirements mentioned earlier in the paper, through assisting the maintenance engineer to isolate engine fuel feed failures down to one failure and an associated component whilst reducing down time. However it requires the addition of a new sensor and therefore additional weight and cost as well as associated integration effort. This is a very simplified view of the real world, where the location of the sensors will make all the difference in the resolution of faults. C. Trade-off Analysis The final stage of the case study considered a simple tradeoff analysis between the two competing HMS designs. The 5 trade-off analysis was used to introduce the concept of using sensor attributes in the HMS and aggregating their values to the associated top level requirements and stakeholders. In this simple proof of concept case study three attributes were used: x x x Cost: purchase cost of sensors Weight: weight of sensors Power: power consumption generating health data of sensors for Clearly other attributes can be associated to the sensors, for example, reliability, accuracy, resolution, repeatability, environmental performance, maintenance cost, etc. Each of the sensors shown in Fig. 4 and 5 were given arbitrary values for these attributes as described in Table 2. Existing sensors were classed as legacy components and had no additional cost or weight impact on the HMS. However a level of power consumption was assumed for generating the additional health data. Fig. 6 shows the simple trade-off analysis between the two HMS designs based on an arbitrary overall HMS design budget of 50/50/40 for the three attribute categories of Cost/Weight/Power. assumed for each of the legacy sensors to process the new information required by the HMS. This design required approximately 21% of the given HMS design budget but only allowed isolation of failures down to one or three components, depending on the failure type. The HMS design shown in Fig. 5 gave a total cost/weight/power impact of 50/20/40 on the arbitrary HMS budget for isolating fuel feed failures down to one component. This design required approximately 80% of the total available HMS design budget. Given the above information an informed trade-off decision could then be made by considering the cost of: x The extra effort required by the maintenance team to isolate the three failures down to one failure and its associated component. Versus x TABLE 2 Pulling all three components in an attempt to reduce the maintenance effort and down time, increasing the support costs by sending them all through the repair cycle for two to return with no fault found. Versus Sensor Pressure Throttle Flow Probe Cost Weight 50 units Legacy Sensor Legacy Sensor Legacy Sensor 20 units Legacy Sensor Legacy Sensor Legacy Sensor Power 10 units 10 units 10 units 10 units For the purpose of this demonstration, the cost/weight/power impact on an HMS design was calculated for the top level (stakeholder layer) by simply adding together the respective cost, weight and power values for each of the sensors as stated in Table 2. This is shown in Fig. 6. More sophisticated relationships can be developed to calculate top level values depending on the type of sensor attributes required. x V. CONCLUSION The case study presented in this paper is taken from a larger case study incorporating several stakeholders with an interest in the health of the given fuel system. The case study described in this paper has been limited in scope to aid clarity in presenting the concept for managing this information and developing a HMS design. The analysis in this paper assesses two HMS designs through the additional cost, weight and power required to develop an HMS and allows a quantitative analysis of candidate solutions. Although the case study has been limited in scope, it has highlighted the following key concept features: x Fig. 6. Trade-off Analysis The HMS design shown in Fig. 4 made use of only existing sensors on the fuel system so no additional sensor cost or weight was incurred. However an additional power usage was The additional cost and weight impact on the UAV platform of adding a new pressure sensor and integrating it in to the overall platform HMS. Holistic Engineering Design Integration The concept allows consideration of both the stakeholders and their requirements as well as the HMS design and its component sensors. Through considering these soft and hard system design aspects under one design process, the concept facilitates the HMS design engineer to make more informed and holistic design decisions. x Traceability of Requirements The concept has shown how stakeholder information requirements can be related down to actual sensors and data flows. Therefore any change in the stakeholders, their requirements or the platform system can be traced top-down or bottom-up to identify the need for any appropriate HMS design changes. x Attributes Aggregation & Trade-off Analysis The principle of using HMS sensor attributes for supporting informed trade-off analysis between the stakeholders or their conflicting requirements has been demonstrated. In reality system design attributes such as cost, weight and power cannot be simply aggregated upwards, however for the purpose of demonstrating the principle a simple aggregation was assumed. Other attributes such as reliability, accuracy of the data and availability may prove even more complex to flow up to the requirements and stakeholder layers. However appropriate algorithms can be developed to model the correct relationship to flow up such attributes. x Visual Design Decision Making Complex systems such as UAVs can generate a large volume of stakeholders and associated requirements within the supportability context alone. The ability to consider this information in a visual manner which supports trade-off analysis and decision making can help remove some of the difficulties in handling and processing such information. The graphical approach for developing an HMS design (as shown in Fig. 4 and 5) is expected to help in this way. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] UK MoD, “Defence Industrial Strategy – Defence White Paper”, 2005, pp 27-28 House of Commons Defence Committee, “Delivering Front Line Capability to the RAF – Session 2005-06”, Jan 2006. US DoD, “Department of Defense Directive – 5000.01” Certified current as of 20th Nov 2007, May 2003. Rolls-Royce “Total Care Webpage”, Link: http://www.rollsroyce.com/civil/services/totalcare/index.jsp, Accessed 26th March 2010. M. Terrett, “TotalCare – The Dependable Way of Life”, Presentation Slides on Rolls-Royce Web Publication Link: www1.rollsroyce.com/media/presentations/services3.pdf., Accessed 26th March 2010, 2005. M. Khella, R. Dixon and J. Pearson, “Designing Health management Systems: A Holistic Approach” International Conference on Systems Engineering 2009, ICSE, 2009 M. Khella, J. Pearson, R.Dixon, D Ciric, I Day, R King, J. Milnes and R. Stafford-Allen, “Systems Approach for Health Management Design: JET Neutral Beam System Case Study”, 2009, unpublished. P.J. Bennett, J.T. Pearson, A. Martin, R. Dixon, M.C. Walsh, M. Khella and R.M. Goodall, “Application Of Diagnostic Techniques To An Experimental Aircraft Fuel Rig” SAFEPROCESS 2006. 6th IFAC Symposium on Fault Detection, Supervision and Safety of Technical Processes, IFAC, 2006.