Integrating IVHM and asset design

Integrated Vehicle Health Management (IVHM) describes a set of capabilities that enable effective and efficient maintenance and operation of the target vehicle. It accounts for the collecting of data, conducting analysis, and supporting the decision-making process for sustainment and operation. The design of IVHM systems endeavours to account for all causes of failure in a disciplined, systems engineering, manner. With industry striving to reduce through-life cost, IVHM is a powerful tool to give forewarning of impending failure and hence control over the outcome. Benefits have been realised from this approach across a number of different sectors but, hindering our ability to realise further benefit from this maturing technology, is the fact that IVHM is still treated as added on to the design of the asset, rather than being a sub-system in its own right, fully integrated with the asset design. The elevation and integration of IVHM in this way will enable architectures to be chosen that accommodate health ready sub-systems from the supply chain and design trade-offs to be made, to name but two major benefits. Barriers to IVHM being integrated with the asset design are examined in this paper. The paper presents progress in overcoming them, and suggests potential solutions for those that remain. It addresses the IVHM system design from a systems engineering perspective and the integration with the asset design will be described within an industrial design process.


INTRODUCTION
Integrated Vehicle Health Management (IVHM) transforms raw sensor data into useful information regarding the present and future condition of a vehicle, to systematically address all likely causes of failure. It uses a vehicle's sensor data to detect faults in components and subsystems (i.e. diagnostics), or to predict the remaining useful life (i.e. prognostics), in order to assist maintainers and operators. This results in optimized maintenance actions, improved readiness and availability, reduced redundancies, extended product life and improved vehicle safety. IVHM technology has been widely recognized over the past decade as a ground-breaking concept in the aerospace, marine and transportation sectors. The set of IVHM technologies are also essential to enable servitization for firms that have traditionally focused on the design and manufacturing of assets. IVHM enables the development of new business models in which the Original Equipment Manufacturer (OEM) does not sell the asset, but instead sells the asset's use. The result is higher income or broader market penetration for those companies that seize this opportunity, as evidenced by Rolls-Royce (2015 Annual Report) where around 50% of the company income is derived from services.
While benefit has been realized in using IVHM to inform maintenance and operation activities, the design of the IVHM system has, to date, been treated as added on to the asset design, something that is incorporated when the asset design has matured, usually feeding off the control system sensors. In order to fully realise the benefits of IVHM it is imperative that it be treated as a sub-system and integrated with the asset design process, elaborated on below. In this way, a coherent plan for the IVHM system can be enacted, incorporating architectural and algorithmic decisions that interact with the design of the asset. Unfortunately, in order to reach this state, there are a number of quite major barriers to be overcome; these are the subject of this paper.
The development process of any asset is driven by the need to satisfy a business demand or to support other assets. It is the responsibility of the design team to achieve a technical solution which is typically achieved by following a systems engineering development process. This considers the complete lifecycle of the asset including the business case, architecture, design, verification, and validation ( Figure 1).

Figure 1. Systems Engineering V-Model Development Process
Benefits to the various stakeholders of 'designing in' the IVHM functionality include: • Benefit from Designers' perspective: handling a new design is easier than adding to an existing one. Tradeoffs can be studied, for example does the designer drive the reliability of a component higher or monitor it in operation? Integration of sub-systems with IVHM functionality becomes possible.
• Benefit from Project Managers' perspective: V&V (Validation and Verification) of the IVHM design is carried out simultaneously with the V&V of the Asset. A more intimate relationship with the supply chain results if components and sub-systems are to be delivered 'health ready'.
• Benefits from Users/Operators' perspective: More affordable readiness and availability levels, reduced redundancies (e.g., vehicles, spares, sub-systems, support, crews, maintainers), provide a competitive discriminator in maintenance operations.
• Benefit from the Business perspective: increased revenue or expansion, enabled by analytical services translating sensor data into business information.
In this paper, a generic industrial design cycle will be used as a reference against which to present the integration of the IVHM system design within the asset design. Barriers will be identified and their possible solutions discussed. While the word vehicle will be used generically throughout this paper, most of what is written has an aerospace and aircraft bias but is applicable to other vehicle types.

BACKGROUND REVIEW
A literature review of work that has been done under the broad topic of IVHM System Design revealed the following, clustered under headings for convenience.
Life Cycles. There are various life cycles for asset design in the open literature, e.g. NASA (Forsberg, 2005;Kapurch, 2010), CADMID (MoD, 2014), and SIMILAR from INCOSE (INCOSE, 2007). Very few papers have been written on industrial design systems, primarily because they are the intellectual property (IP) of the OEMs. These design systems have, however, existed for a number of years, withstanding the test of time and been shown to be robust while producing novel designs. There are also very few published papers on IVHM (or Prognostics and Health Management, PHM) system design. One exception are the papers by Walker (Walker, 2009 and2010) where, instead of merging IVHM design and asset design, the problem is viewed from the steps in the RCM (Reliability Centered Maintenance) process.
New Business Opportunities. Typically, the engineering process starts with the identification of a new business opportunity, and ends with an asset that fulfils the specification. This process contains a number of wellestablished stages -specification (requirements capture), concept (conceptual design), preliminary layout (preliminary or front end engineering design), definitive layout (detailed design), verification, validation, testing and documentation (Pahl and Beitz, 1988). The typical V design cycle ( Figure 1) with requirements, specification and V&V flow down the LHS and, as the components, sub-systems and systems are designed, V&V demonstration proceeds at the various levels up the RHS. This design cycle has been used for many years, with many Technical/Business Gates (audits) to be passed as the design matures. The concept phase of the design process has become more complicated with servitization (Tukker and Tischner, 2006) since this moves away from selling a product to selling a service, and hence affects the fundamental set of requirements imposed on the design team. The relationship between Owners, Suppliers, Maintainers, Operators and Regulators of highvalue assets becomes fuzzy as new business models are created and the value chain becomes increasingly more complex. Examples of contracts based on such ideas include: Boeing's GoldCare, Airbus's Airman, and Gulfstream's PlaneConnect. This also illustrates that requirements capture is needed from as broad a set of stakeholders as possible -marketing, sales, operators, maintainers, etc.
Requirements. Within the transition from product (sale of goods) to service (sale of use of goods) mentioned above, the number of stakeholders increases and also the relationship between them becomes more complex. Therefore an integrated requirements capture process is needed for the development of assets with IVHM capabilities. Servitization shifts the derivation of reliability and maintainability requirements from what a client (purchaser of the asset) demands to a set of requirements defined as a result of a series of trade-off analyses that compare higher system reliability against higher IVHM capability. This integrated requirements capture process considers the trade-offs for optimising reliability and maintainability, design and manufacturing cost, and operation and maintenance costs; all while getting the agreement of all stakeholders. Bartz and Reisig (2008) introduced a domain requirement summary technique that allows the implementation of the requirements capture process. There are also a number of emerging recommended practices from SAE that describe the steps of requirements capture and management, and the way it can be aligned to the SIMILAR process from INCOSE (Saxena, 2012;Rajamani, 2013).

Retrofitting.
A series of studies investigated integrating IVHM solutions into legacy systems (Esperon-Miguez, John and Jennions, 2013) highlighted the organisational challenges related to development and implementation of health management (HM) capability. This is clearly more difficult for a legacy vehicle than a new one due to access restrictions and interfacing to existing equipment. To counterbalance this, the business case is easier, as the fault modes that the IVHM equipment is being designed to monitor, are known.

IVHM system design.
A few authors have addressed the problem of how to design an IVHM system, e.g. Walker (2009), Keller (2007, and . Nobody has made the next step of how it is integrated with the asset design -which is the topic of this paper. The lack of a unified framework to support IVHM design as part of Asset Design was highlighted by Keller et al. (2007), who introduced a top-level framework capable of supporting the construction of IVHM solutions. The proposed framework is not presented in the context of the Asset Design, instead it highlights the development and implementation of HM solutions within a dedicated standalone process using specific COTS software tools. The same process was employed by Wilmering (2008) to highlight the importance of component/system's model reuse in support of IVHM application integration.  captured the interactions between different types of information and knowledge required by the IVHM design activity and the fact that IVHM design relies on input from many engineering disciplines (safety, reliability, etc.). Wilmering also highlighted that IVHM Design spans across all branches of the engineering organisation and its development is hard to control given current processes.
Testing. Ofshun (2007) highlighted the challenges faced by test engineers throughout the V&V of the IVHM systems (in a virtual environment) as IVHM capabilities are difficult to effectively test prior to deployment. One major challenge in implementing the IVHM solutions is the identification of its characteristics for various operating regimes of the asset. On the same topic, Wilmering (2003) explained why IVHM maturation is still a difficult task. Many experts in the IVHM field highlight that the design of testability solutions (capable of working at the system level) is not a straight forward job and it should be built on the knowledge of all interactions between system's components when the system is new (Sonderholm, 2007;Pecht, 2008) but it must also consider these interactions when the system is affected by physical degradation. The topic of systems' testing has evolved from methods underpinning the construction of troubleshooting manuals, to deployment of Built-In-Test (BIT) capability to the use of IVHM technology in supporting the maintenance activity. Regardless of the adopted approach, it has been identified that testing should also incorporate the organisational and human factors in troubleshooting (Morris and Rouse, 1985) and its performance should rely heavily on the estimation of fault detection (FD), Fault Isolation (FI), No Fault Found (NFF) and Ambiguity Group (AG) figures (Simpson et al., 1986).

Design for Service / Cost-Benefit Analysis.
In the context of servitization the focus of the OEM is gradually shifting to the availability of the asset and also to the end user/operator. Therefore Design for Safety/Design for Maintainability are evolving towards Design for Service and this approach should be considered in the context of different Concepts of Operation (ConOps), tailored for different users of the asset. The same asset might have different IVHM solutions if it is sold to different operators who will be servicing and maintaining it in different regimes. Cost-Benefit analyses are a very strong instrument (capable of handling the complexity of different ConOps regimes) in taking informed decisions related to the IVHM system design as the program progresses through different technical and business gates (Sandborn, 2007;Sandborn, 2008). As the IVHM solution approaches realisation, it will trigger certain organisational, business and management changes at the Owner, Manufacturer and Operator levels (Grubic, 2014).
Organisational culture. According to MacConnell (2007), the culture and mind set of an organisation are two major barriers in adopting IVHM capability at the beginning of a program. Two of the recommendations from this study are: the shift of the focus from reactive health management to proactive health management based designs and the promotion of collaborative development. IVHM system design must be raised to the status of a system engineering discipline and a common definition should be agreed between all the stakeholders at the beginning of the program. Building on the same idea, Scandura (2005) presented IVHM as a system engineering discipline, proposing an enterprise-wide approach for the IVHM system design using six phases: system design and build, dispatch preparation, mission operation, checkout and repair, post-mission analysis and system enhancement. Lack of IVHM field experience. Information on how IVHM solutions react in the field is needed to construct business cases that will enable IVHM to buy-in its way on to the Asset.
Partial solution is to run an enterprise wide cost-benefit analysis, backed-up by a flexible decision process.

2
It is not clear how to flow down the IVHM requirements derived from Asset requirements. Top down or bottom up approaches can be employed but quantitative goals are difficult to set.
Requires a shift in the organisational culture, based on good systems engineering principles.

3
In new asset design, a good understanding of the system behaviour under healthy and faulty conditions is not available upfront.
Extend modelling with design system tools to faulty conditions (simulation), supplement with more field data.

4
Failure mode engineering analysis is difficult to use in the construction of an IVHM solution.
Commercial tools are available, need to be adopted.

5
Proven trade-off studies capable of identifying the most cost effective solution between redesign, redundancy and instrumentation of an asset are not available.
Commercial tools are available, need to be adopted.

6
A systematised sensor placement process that can be easily employed and readily re-used for different sub-systems and complex platforms is not available.
Commercial tools are available, need to be adopted.

7
Exchange of information between OEM, manufacturers and suppliers.
Trust and IP need to be addressed. Including standards, such as OSA-CBM, and those from organisations like SAE, will be helpful.
8 IVHM capabilities are difficult to comprehensively test prior to deployment.
Accelerated testing and fault seeding need to continue, but there is a case for virtual simulation to cover the expanse of the faults to be detected. He also introduced the concept of IVHM system design layers, re-enforcing the role of the HM integrator, responsible for the coordination and integration of all IVHM activities across the program.
Standards. IEEE has been working to expand its existing test and diagnostic standards to address IVHM requirements (Sheppard, 2006). IVHM could not have been established as a distinctive engineering discipline previously because most past initiatives were addressing the IVHM system design in isolation, targeting specific components, sub-systems, applications, products, processes or industries. Another finding of the Sheppard study emphasized that these standards are not addressing the bridge between the technical design decisions and business decisions involving the development of the IVHM function, echoed by Vogl (2014). More recently, the SAE HM-1 committee has been developing Aerospace Recommended Practices containing guidelines in many of these areas. This work is on-going with progress being reported by Holland et al (2016), and Rajamani et al (2013), ahead of the standards being released.

INTEGRATING IVHM DESIGN WITH ASSET DESIGN
The industrial asset design process as used by Meggitt PLC is shown in Figure 2, and is reproduced here with their permission. It is typical of an industrial asset design process and will be used as the background against which to discuss, in the following sections, how IVHM should be integrated into the asset design, where the barriers exist, and potential solutions to overcoming them. The barriers can occur more than once in the process, but they are only shown in Figure  2 where they cause the most trouble.
A complete list of the 8 barriers discussed in this paper are shown in Table 1. The table is positioned here for reference, the actual barriers and their potential resolution being discussed in full as the barriers arise in the following text.

New Opportunity Assessment
Companies are constantly talking to their supply chain, watching competitors, consulting potential customers, and performing Research and Technology, all with a view to the development of the next product. This phase deals with the identification of these new market opportunities, which in the aerospace sector revolves around maximizing product availability and reducing the through-life ownership cost. Many different opportunities are examined, assessed, refined and discarded compared to the few that proceed. Depending on which part of the supply chain is examined, this decision could affect the company's revenue stream for decades, e.g. the choice by a plane manufacturer as to their next model, wide body versus single aisle.
Previously, the business model driving this stage was viewed as the sale of the product, with further income being dependent on spare part sales as the asset aged. Recently, however, the sale of a service (the use of the product) has become more popular. In this business model the customer / operator pays a monthly fee in return for the leasing and maintenance of the asset. This type of business model is called servitization by some (Vandermerwe and Rada 1998), and PSS (Product Service Systems) by others (Tucker and Tischner 2006). In either case, IVHM is the underpinning capability that enables this to happen in an effective and risk reduced manner, monitoring and managing the asset to allow for timely maintenance -hence the argument for IVHM having to be integrated from the start of the design process.
Within the scope of this paper, this opportunity is represented by a service contract capable of enabling the reduction of through-life ownership cost. The business opportunity can materialize in a number of different ways, for example: • Improvement of maintenance efficiency; direct cost saving. This may be approached via maintenance credits for the IVHM system (SAE, 2016).
• Improvement of effective reliability; better maintenance planning.
• Life extension of legacy system; cost benefit.
• Replacement of scheduled maintenance by guaranteed maintenance free periods; better parts usage, cost advantage.
A barrier to the realisation of these opportunities is that there is not enough field data and examples of IVHM success to aid its adoption and inform the business case (Barrier 1).
There are guidelines on how to perform business cases in the literature, including recent guidelines by industry and government agencies to drive decisions related to through life support system strategies (Cortez et al., 2008a;Cortez et al., 2008b;Johnston, 2008). The adoption of IVHM capability as part of the asset design through a systematic process has proved to be a very difficult task for large enterprises or for large programs (Hess et al., 2006). This is, in part, because success in performing a business case analysis depends on the organisation's knowledge of the asset in operation and its effectiveness in communicating this knowledge among the stakeholders, a cultural shift for an historically product driven company. Two other elements contribute to the success of a business case: a) the ability of the enterprise to correctly capture the baseline of the business case analysis (As Is), and b) the ability of an enterprise to articulate a decision process accurate enough to reflect the needs of all its stakeholders and also to support the proposed alternatives (To Be). These issues have been explored in recent works by Heaton (2014) and Esperon-Miguez, John and Jennions (2013).
The approach is to produce an enterprise wide cost / benefit analysis. At this stage it will contain uncertainty about many parameters; these will be continually refined as the process progresses. This model must be able to simulate the effect that an IVHM system can have on an asset's maintenance cost and availability, i.e. the benefit. It also should estimate the investment necessary to develop, implement, and operate the new system, i.e. the cost. This model should provide quantitative insights, by highlighting the resulting costs and benefits, into possible design alternatives capable of supporting the service contract (Wilmering and Ramesh, 2005;Williams and Poblete, 2006;Williams, 2006).
The enterprise model should account for: assets, policies, processes, procedures, historical data, stakeholder's objectives and it should accommodate analysis for different scenarios related to concepts of operations, support strategies, financial analysis and evaluation of alternatives (Keller et al., 2007). The model should also capture the business and operational relationship between the OEM and the customers or regulatory organisations. The decision process can be characterized by metrics like: availability, schedule reliability, maintenance resource utilisation, Return On Investment (ROI), and Net Present Value (NPV). It is understandable that these metrics will have different weights for different stakeholders.
The risk of the investment is essentially the probability of the IVHM system failing to perform as expected, principally due to the lack of in-service data (Barrier 1). The uncertainty caused by lack of information, which Walley (1990) classifies as epistemic uncertainty, can lead to a series of assumptions made during the design process that include, amongst others, scenario abstractions or system behaviour uncertainties (Lopez and Sarigul-Klijn, 2010). Consequently, one of the main sources of risk is the possibility of overestimating the performance of the IVHM system, which can be diminished by modelling and understanding the system and its Concept of Operations (ConOps). By integrating the Asset Design and IVHM Design all the models used in the early stages of the design process can be brought together to provide a better understanding of the vehicle capabilities and how it will be operated and maintained. This results in a more accurate business case, where the calculations for the financial risk can be revisited throughout the development cycle as models improve and data becomes available.
Essential to the business case analysis, at this stage, is that there exists consensus between internal stakeholders. This will include agreement on the enterprise model and the decision process used to calculate the costs and benefits when considering an asset with IVHM capability versus an asset without it. If the IVHM Design is integrated with the Asset Design, it will be significantly easier to reach this consensus and to monitor that the value and business propositions are delivered as the program moves to the next phase.

Proposal
This phase delivers a business and technical proposal integrating the business model (how the company will make money) alongside the risks being taken. It will also capture all of the stakeholders' requirements, principally external but also internal. The result of this work will also include a conceptual design of the system that will be developed in further detail in the following stages of the design process.
All this information will inform the business model and any simulation being performed to look at 'what if' scenarios, built around the ConOps. It will inform as much of the supply chain as needed to mitigate risk and engage customers as to quantities and delivery schedule. Sufficient conditional orders will need to be taken after this stage to warrant proceeding.
The link with IVHM in this phase is through risk mitigation. If a service is being offered, what are the guaranteed service time, maintenance periods and availability? For each of these an IVHM solution that mitigates the risk to an acceptable level must be found. Here, and throughout the design process, IVHM must be considered as one of the vehicle's sub-systems, and treated as a system engineering discipline (Scandura, 2005). A budget will be set for the IVHM group in the same way as for any other sub-system.
It is not clear how to derive the IVHM requirements, as IVHM has so many stakeholders and touches all parts of the organisation. The IVHM requirements have to be developed from Asset requirements, but the complex nature of IVHM presents a barrier at this stage (Barrier 2). Datta and Squires (2004) presented a process capable of quantifying the IVHM requirements using Event Tree Analysis (ETA). In their approach, IVHM systems are considered to be comprised of diagnostic tools. The requirements for these diagnostic tools are then calculated taking into account maintenance cost and safety. Top down or bottom up approaches can be employed but quantitative goals are difficult to set. For example, consider what happens when a top level quantitative goal is set, aligned to a business case. This goal would be cascaded down to each constituent part of the system and could well result in levels of performance that are not achievable. Added to this is the problem that it will take many years of the system in the field to accumulate enough detection data to substantiate the goal set, or not. Similarly a bottom up approach, with reasonable Fault Detection and Isolation (FDI) figures attributed to each component system could well end up with an overall (cumulative) performance that was at variance with any goal. This is not to say that work should not proceed and that systems can't be tuned in the field, it is just that achievement of the design goals are, currently, very difficult to prove.

Figure 3. Asset and IVHM requirements
A proposed flow down process for the capture of IVHM requirements is depicted in Figure 3. Established links are shown as solid lines and those that need to be made or strengthened shown as dashed. Only the top half of the diagram is addressed here, RFPs come into the next design phase. From the system integrator (OEM) point of view, the IVHM requirements should be derived from the asset's requirements by taking into account safety, reliability and maintainability considerations. Starting from the left hand side of Figure 3, the asset requirements are cascaded to define business, operational, safety, reliability and maintenance requirements. IVHM, as a capability adopted to create value for the OEM, and also for the final customer of the asset, should underpin these requirements.
The definition of IVHM requirements should be an iterative process that takes into consideration the trade-offs between imposing higher safety, reliability and maintainability requirements on systems and components, against improving the accuracy and precision of a condition monitoring system. By treating the IVHM as another integral subsystem of the vehicle, this analysis would take place at the same time as other trade-offs between vehicle systems are being considered. These trade-off analyses should also be informed by the business case developed in the previous phase. We identified four different links that had to be strengthened within this phase of the requirements capture process: the link between the Asset Function requirements and the IVHM function requirements; the link between the Asset Performance requirements and the IVHM function requirement; the link between the Asset Function requirements and the IVHM Performance requirements; and the link between the Asset performance and the IVHM Function requirements.
Once the product requirements (top layer in Figure 3) were established, process requirements (bottom layer in Figure 3) related to acceptance criteria and program management should also be identified to ensure a clear implementation route for the IVHM system alongside the asset itself. As mentioned earlier, for the design and development phase, the IVHM team will receive a budget and will construct the delivery schedule in the same way as any other sub-system. The integration of the IVHM requirements capturing process within the asset requirements capturing process triggers the inclusion in the Request for Proposal (RFP) document of IVHM specific targets like: failure detection, failure isolation, failure prediction, false alarm rates (false positives and false negatives), no fault found rates, confidence levels, uncertainty, precision, accuracy. As with any sub-system, the requirements gathering process, requirements analysis and requirements prioritisation results in multiple iterations in which the functional and performance breakdown of the asset and its IVHM system are adjusted until the design team agrees on a solution (Karlsson and Ryan, 1997;Hooks and Farry, 2000).
Further on, designers use functional models, FMECA, and initial physics models of the asset to evaluate the pros and cons of each configuration. This becomes the preliminary design on which the following stages of the design process are built.
Unfortunately, this top-down approach has not been widely adopted so far, as evidenced by the very few vehicle level, or even system level, IVHM systems compared to the number of condition monitoring solutions focused on components or small subsystems. More often, the approach to IVHM development is usually bottom up, where known IVHM solutions are plugged into an asset without a clear link to asset level requirements and sometimes even without having clear IVHM requirements.
This failure to follow a Systems Engineering practice can lead to costly surprises later in the detailed design or V&V phase. Examples from many industry sectors have highlighted that a lack of understanding of the effect of faults throughout a system contributes to false positive and false negative rates. However such an understanding would never eradicate these rates as they are principally due to uncertainty.
Reliability analysis, formal design methods, function-based design methods, function-based failure and risk analysis methods, design for testability methods and systems analysis and optimisation methods were conceptually employed to support the top-bottom IVHM design approach but they have not been implemented and need to be verified and validated on real programs (Wirth et al., 1996;Kumar et al., 2000;Lee, 2001;Ofsthun, 2002;Price et. al, 2003;Tumer and Stone, 2003;Stone et al., 2005a;Stone and al., 2005b;Hess et al., 2006;Banks et al., 2009).
A conceptual framework (that employs a top-down approach) for the fault management design methodology was presented by Johnson and Day (2010). The study presents the design of the fault management function as an extension of control theory and it only tackles the fault management, an operational subset of the IVHM system.
It is also in this stage that the health management system starts to be defined. It can be treated as an individual feature of every sub-system or it can be architected as a unique vehicle capability reaching into multiple subsystems. The second approach (preferred) can be implemented using a Systems Engineering approach as depicted in Figure 4, where the top two blocks (Requirements and System Analysis) align with, and expand on, the right hand side of Figure 3.
The requirements development and performance/functional analysis will have a direct impact on Phases 2 and 3 -Preliminary Design and Detailed Design. The goal of the requirements development stage is to determine the most affordable manner in which each asset development partner can contribute to an acceptable overall technical asset design, and then to enact an effective organisational infrastructure to manage the asset development process. This will be highly dependent on the degree of subcontracting. (Wilmering and Ofsthun, 2006) The requirements flow down (Barrier 2) can only be overcome by a shift in the current organisational culture through:

Figure 4. IVHM Systems Engineering Process
• Well-formed design teams, which should include the IVHM design analysts, RAM (Reliability Availability Maintainability) analysts, and maintenance personnel • Clear understanding of the mutual goals shared between various stakeholders • Clearly established program management criteria • Documented processes and tools The IVHM requirements capture process is a complex topic and is the subject of a PhD thesis by Heaton (2014).

Preliminary Design
With the technical groundwork done, the next two stages are continual refinement of the design. Embedded in the opportunity stage will be challenges on performance, weight and cost that have now to be refined. At the end of this stage the 80/20 rule is appropriate, with 80% of the cost of the asset being embedded with only 20% of the design time taken (Lidwell et al., 2010). Each sub-system will have its own challenges and the use of new technology will be carefully monitored by the project to record and mitigate the risk. For any risky technology, there will be a fallback position, but usually at a cost of not making a performance or weight goal.
For the IVHM sub-system this is a busy stage. Architecture, as defined by: 'the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time' (IEEE Std 610.12), has to be laid out, for the asset and the IVHM system simultaneously. IVHM decisions include how to create a coherent system involving both on-board and off-board elements. Standards such as OSA-CBM provide a functional framework, defining the interfaces between different levels, and enable sector specific solutions. This is made more complicated in that the IVHM system has to interact with every other sub-system in order to perform correctly. A roll up of the risks that are being mitigated with IVHM should be made along with the associated cost, thus justifying continuation on a case by case basis. Alongside the architecture, the design is refined, and suitable FDI techniques have to be adapted to new components or systems.
As part of the evolving architecture, a dialogue with possible suppliers begins. It is in the interest of both the OEM (platform integrator) and the system supplier to be able to detect and diagnose faults in order to keep the customer satisfied. While the OEM can put forward a specification for the supplier to produce a 'health ready' sub-system, this opens up a number of questions. IVHM systems are built by multi-organisation teams driven by a fully documented request for proposal (RFP) which will be flown down to the supply chain during the component selection process. The RFP will contain figures related to failure prediction, failure detection, failure isolation, and false alarms (false positives, false negatives, and No Fault Found), initiated in the Proposal phase. This demands transparency, as to how these figures will be met, from both OEM and suppliers, who might be reluctant to share what they consider to be part of their Intellectual Property (IP).
This leads on to a trust concern, where the supplier could be revealing faults in operation to the OEM before, or at the same time as, they are seeing them. This is, naturally, a sensitive subject, and needs to be thought through at contract negotiation. Both IP and trust issues lead to the potential for difficulty in communications, referred to later as Barrier 7. There is also the question of how the system will be tested, to show contractual compliance, against the OEM's specification. This aligns with Barrier 8 (which will also be discussed later), but is made more complicated as it's with a third party. Another question is who owns the data coming off the sub-system? Historically this has been the operator but, to provide the service, the supplier and OEM would have to have access to it; another contractual issue.
The main barrier affecting the design of the IVHM system in this phase is that there is not a good understanding of the system behaviour under faulty conditions (Barrier 3); the asset design has concentrated on the healthy asset without considering degradation. What understanding exists comes from previous experience, prototyping, trials and testing. The result is greater uncertainty when it comes to making design decisions. The work of Lopez and Sarigul-Klijn (2010) on the effect of uncertainty on structural damage monitoring identified operational scenario abstractions, signal processing, or modelling approximations are some of the key drivers of uncertainty.
Unfortunately, the entire picture will only be complete once the system is in service under real conditions; therefore the IVHM system itself should be tested with the same rigour as the asset itself (in order to minimize the number of false positives and negatives in service).
During preliminary design analysis, sensitivity studies are carried out to identify the components/system performance in order to meet the specified technical requirements. When IVHM is not part of the asset design process, the system's designer will only address the healthy scenarios of the asset in service and the degradation phenomenon of various components and their effects on the system performance will be tackled through built-in tests or scheduled regular maintenance tasks (compiled using input and recommendations from component supplier). This approach works but sometimes, critical components fail between regular maintenance interventions or components are replaced too early (Blanchard et al., 1995;Narayan, 2004;Gulati, 2012). This translates into significant costs for the final user of the asset. IVHM, as a capability, can address these issues and in order to be successful, the IVHM preliminary design analysis has to accommodate two main dimensions: identification of the top critical components within the asset and the physics-based understanding of the degradation phenomenon for each of these critical components. This systematic approach will allow the identification of features to be monitored and allow fault detection and fault isolation of each individual failure mode considered for the IVHM analysis. Once this solution has been identified and optimized, architecting the IVHM solution is the next challenge within the IVHM design process. Currently, Open System Architecture for Condition Based Maintenance (OSA-CBM) is considered to be a good reference model for IVHM solutions and various instantiations of this framework for distributed embedded application are present in the literature (Sreenuch et al., 2013;Sreenuch et al, 2014). It is important to consider at this stage, the division between on-board and off-board capability under which IVHM has to be implemented and deployed. Niculita et al (2013a) introduced an IVHM development process capable of answering some of the IVHM design related questions. These are questions such as: 1. What types of IVHM design analyses are required to be performed in order to assess the impact of failure modes throughout the system? 2. What types of sensors should be used and where should these sensors be placed in order to detect and isolate a given fault?
3. How should the diagnostic and prognostic functions be constructed in order to support detection, isolation and prediction of given failure modes?
The process aligns a systematic functional representation of the system and the effects of functional failures throughout the system against the physics-based analysis of the system under healthy and faulty scenarios.
The quantitative physics-based models associated with a given system contain the mathematical-based knowledge supported by the ground truth experience-based information captured throughout the service of previous generations of similar models. Within the proposed development process, the 1D physics-based models of the asset are considered to be the foundation of the IVHM design.
The integration of quantitative and qualitative dimension of a system to support the IVHM function was studied more than a decade ago (Struss, 2002). The lack of tools for construction of a functional model led the research community to abandon the use of functional modelling for IVHM design. A functional model is capable of generating a qualitative fault propagation table that contains the fault signatures for the entire failure mode universe considered for the analysis. Since function-based models allow simulation of faulty scenarios strictly from a qualitative point of view, their correctness will be verified against the qualitative extrapolation of quantitative information captured by the physics-based models (Niculita et al., 2013b). All these models will be expanded as more information becomes available during the detailed design phase.
Barrier 3 can be overcome through a correct mapping of the effects (throughout the entire system) of each individual fault on a critical component. Special attention has to be given to cases where faults exhibit bi-direction propagation (down-stream and up-stream) as these are very often missed within traditional risk identification and mitigation techniques. A good understanding of the asset's behaviour under faulty conditions might lead to a different architecture of the IVHM system than the one considered when addressing only the healthy scenarios as a baseline for the preliminary design phase of an IVHM enabled asset.

Detailed Design
The detailed design of the asset begins at the bottom of the V shaped system engineering diagram shown in Figure 1. The requirements have been cascaded down through the previous stages, along with their V&V criteria, to enable the design of component to be completed before ascending the right hand side of the V, performing the verification and validation process. Components from the supply chain will be integrated as this proceeds to form larger systems, and anomalies rectified.
IVHM has a very similar, but more detailed role, as in the last stage. Having agreed on FDI techniques, these will be refined and complemented with prognostic algorithms. Again, the scope is very large, as all other sub-systems have to be covered and addressed. Designers will leverage the IVHM contribution as they strive to satisfy reliability, maintainability and safety requirements. Standards, such as those being written by the SAE HM-1 committee, form a very important part of this stage for IVHM. It is through these standards, and adherence to them, that IVHM will become accepted as an engineering function and a route to certification defined.
There are a number of barriers that contribute to the lack of adoption of IVHM as part of the asset design in this phase. A systematic approach in capturing the effects and criticality of failure modes throughout the system for understanding the system behaviour under faulty conditions is needed (Barrier 4). Some solutions exist but are not widely adopted by industry. Similarly, proven trade-off studies capable of identifying the most cost effective solution between redesign, redundancy and instrumentation of an asset are not available. Attempts to reach a cost optimal solution are undermined by the lack of historic data (Barrier 5, and Barrier 1).
A systematised sensor placement process, capable of detecting and isolating faults affecting system performance after its deployment in service, is needed (Barrier 6). A significant number of HM solutions are developed using sensors targeting symptoms but this approach cannot support a systematic analysis to enable the on-board and offboard IVHM solution. How can a designer define sensor set locations? How can they run sensor trade-off analysis upfront throughout the Asset design stage? How can they run ambiguity group analysis? The more accurate the information related to system's failures and their effects throughout the system, the less false alarms will be triggered within the verification and validation phase of the asset design. Finally, exchange of information between OEM, manufacturers and suppliers is difficult, as discussed in the previous section. This barrier could fall under Barrier 1, but it is specifically addressing a lack of coordination and communication between integrators, manufacturers and suppliers by establishing a process capable to flow-down the IVHM OEM requirements to IVHM supply Chain requirements (Barrier 7). This barrier was also identified by Scandura and Garcia-Galan (2004) and Esperon-Miguez et al. (2013) when highlighting challenges and opportunities for integration of IVHM tools for legacy platforms.
Barriers 6 and 7 have a related opportunity, and that is the utilization of existing aircraft data. Tens of thousands of sensor values are available on the aircraft bus with only a small portion of that output being made available to flight data recorders. Sensors should be used to supplement this existing data where possible, but understanding and obtaining access to that existing system data can be difficult, but ultimately rewarding.
Within the integrated asset and IVHM design process, the IVHM detailed design phase will employ two distinct steps: the quantitative engineering analysis carried out to establish the ground truth information related to system degradation (by using the engineering analysis carried out during the asset detailed design phase) and the qualitative functional analysis performed for the identification and optimisation of IVHM sensor set solutions capable of detecting and isolating failure modes captured within the analysis (Stecki et al, 2014). The effects of more failure modes affecting the same component within the asset can also be captured within quantitative physics-based models (Daigle and Goebel, 2011) and the functional models updated accordingly in order to capture their effects at the system level.
The detailed design phase involves the development of quantitative physics models. These models cover multiple physical domains (e.g. solid mechanics, fluid dynamics, thermal) and are used to ensure that each design solution meets the requirements set for each subsystem and its components. In modern design projects the majority of manhours are now dedicated to the development and verification of these models. Unfortunately, the traditional approach to IVHM design rarely makes use of these models, meaning that those faced with the task of developing diagnostic and prognostic algorithms need to produce their own. Models used for design often consider operating conditions in which the object of the simulation and the systems that surround it are in a healthy state. Whilst this might not be sufficient to develop algorithms for IVHM, they can be used as a starting point, saving time and resources.
In a similar manner, as designers make progress through the health management development process, the FMECA can be updated using a model-based framework. This will use input information from the design team, RAM analysts, and maintenance personnel. This should continue throughout the entire life of the asset -a living FMECA. The effects of failure modes can be missed through traditional failure mode analysis, and therefore they will not be addressed by the IVHM design team. The output of such a FMECA will be then re-used for future programs when not enough knowledge about component or subsystem degradation (and their effects) is available upfront.
Further integration of the Asset Design process and the IVHM Design process is not limited to reusing models. By achieving closer cooperation between the asset design team and the IVHM design team both can benefit from each other's expertise. Knowing, in detail, how the system behaves within the envelope of the vehicle operational conditions helps to reduce the likelihood of a high false positive rate once the IVHM system is operational. At the same time, a better understanding of the physics of failure of a component helps to avoid unforeseen problems in service.
Barriers 4, 5 and 6 can be overcome simultaneously by a good understanding of the system under healthy and faulty conditions. Industry and academia have addressed the physics of failure of different components (batteries, valves, pumps, filters) but these efforts represent just the start of the journey in simulating the degradation of systems as a whole. An accurate picture of system degradation will allow development of trade-off studies (cost, weight, reliability) including redesign of the asset, addition of redundancy for the critical components or addition of instrumentation capable of supporting the IVHM function. All aim to minimize the risk associated with the target asset.

Verification and Validation
The right hand side of the V cycle ( Figure 1) is concerned with testing the developed components and systems against the V&V criteria laid down and flowed from the overall asset requirements. This involves the construction of numerous test rigs, including 'Iron Birds', with which to examine system interactions and hone the overall system behaviours. As the design has progressed from the preliminary design phase it has become much more expensive to fix. It is widely accepted in the software industry that it is 10 times more expensive to fix a problem at the V&V stage than at the preliminary design stage and 100 times more expensive to fix the same problem during the production phase (Boehm, 1987;Fagan, 2001, Arum et al., 2002Hall, 2002, Rainer andHall, 2003;McConnell, 2004). For electronics and hardware in general, fixing problems late in the design process becomes even more costly. It is estimated that the ratio for changes made during Design vs. Design testing vs. Process Planning vs. Test Production vs. Final Production is 1:10:100:1000:10000 (Business Week, 1990). As IVHM comprises of hardware and software, it is good practice to incorporate as much field experience into the initial designs as possible. Processes related to system verification and system validation exist and are clearly documented and they should methodically be adapted and implemented to include the testing of the IVHM technology along with the rest of the other sub-systems (NASA, 2004;US Air Force, 2005;NASA, 2007). However, whereas the V&V of an Asset is relatively straightforward, as it involves testing of the hardware and software for the function that it was designed for, in the healthy state, IVHM V&V is somewhat different. IVHM capabilities are difficult to comprehensively test prior to deployment as it is difficult to construct the degradation that IVHM is intended to assess (Barrier 8).
Running representative tests on an asset is always problematic, because of the time, cost and reproduction constraints involved in capturing any significant degradation. To create any significant degradation requires running over a considerable period of time; this cannot be reproduced easily, and is costly. Three different approaches to this challenge could be taken.
• First, accelerated testing. This can be achieved by increasing the duty of the components or by manufacturing them out of less durable materials.
• Second, by accurately knowing the degradation modes to be investigated, the components can be machined to represent the degraded mode, often referred to as 'seeded fault' or 'fault injection' testing. This only represents one snapshot in the wear process but could be repeated gradually increasing the effect. Simulation may be necessary to aid this process.
• Third, by simulating some degradation modes, to assess systems response, e.g. a filter replaced by a valve, so that a clogged filter failure mode could be simulated by gradually closing the valve.
Barrier 8 can be overcome by the adoption of systems engineering practice throughout the IVHM design process. If IVHM requirements are derived from high-level operational, safety and maintainability, requirements, using such a practice will allow the construction of the testing strategy and the estimation of the level of effort required to V&V an IVHM system. The latter is very useful information as history proved that V&V can be a significant delaying factor in large-scale programs. Graydon et al. (2007) advocated for simultaneously co-development of the system and the V&V program. As it is meant to assess the health of the asset, the IVHM system must be among the most reliable subsystem on the entire vehicle. The IVHM V&V phase should be capable of supporting a suite of activities (analyses, tests, simulations, etc.) under a bottomup approach.

In-Service Support
Having started this asset design with a service contract in mind, this is where the business model comes together. Asset design has been performed with a focus on throughlife, rather than unit, cost.
The IVHM system can continuously be updated/tuned/improved using in-service data. The overall purpose of these actions is to further reduce the FA, FP and NFF figures. Data capturing from the field can also support formulation of best practice and lessons learned to be used by the enterprise across other programs. It can also be used as for the enhancements of business cases for future adoption of similar IVHM solution/design approach for future generation of assets.
The benefits of increased data gathering and analysis capability provided by IVHM are not just limited to improving operational and maintenance support. Through the collection and study of these data, future designs can be improved based on consistent evidence of how the asset was operated and how it performed.
It is important to emphasise that data ownership remains a most important question. Multiple systems and subsystems collect data that cannot be accessed by the manufacturer of the vehicle, and operational data -which is essential for the development of failure and degradation models -is not always made available. A potential solution to this problem is for monitoring algorithms to remain latent while the IVHM systems collect data on the whole fleet. Then, once enough data has been collected, diagnostic and prognostic algorithms can be reliably used.

SUMMARY AND CONCLUSION
IVHM has the potential to improve vehicle maintenance and operation to the standards required by the modern service oriented market. However, if IVHM systems are to become more comprehensive their design must become an integral part of the development process of the asset they monitor. The method presented here follows a top-down systems engineering approach that helps to bring IVHM design to earlier stages in the asset design process.
Eight barriers to the full inclusion of IVHM as a sub-system and integral part of the asset design have been identified (Table 1). They have been discussed in the text and are summarized below, with the Section in which they appear.
In the New Opportunity Assessment phase (Section 3.1) the difficulty in constructing business cases that will enable the IVHM design to buy itself onto the asset was discussed. Lack of IVHM field experience was identified as Barrier 1 and can be partially overcome by running cost-benefit analysis through a comprehensive enterprise model backed up by a flexible and representative decision process for parties involved in the definition, development and exploitation of the IVHM capability.
In the Proposal phase (Section 3.2) the difficulty in defining the IVHM requirements was addressed (Barrier 2). A top down iterative approach was proposed by deriving the IVHM requirements from business, operational, safety and maintenance requirements. This can be realised by a shift in the current organisational culture through well configured design teams, and a clear understanding of the mutual goals shared between various stakeholders.
The Preliminary Design phase (Section 3.3) encounters the problem of not having an upfront understanding of the system's behaviour under faulty conditions (Barrier 3). This barrier can be overcome through a correct mapping of the effects of each individual fault by employing simultaneously design, safety, reliability, availability and maintainability knowledge. Another challenge derived directly from this barrier is that sometimes this knowledge resides outside the OEM's organisation.
The Detail Design phase (Section 3.4) requires the highest level of integration and, for this reason, many different challenges were identified in this stage. FMECA and current techniques for failure mode analysis are not documented throughout the entire life cycle of an asset and also they cannot be easily employed to support the design and development of IVHM functionality (Barrier 4). Proven trade-off studies capable of identifying (at the system level) the optimum solution between redesign, redundancy and instrumentation of an asset are not available (Barrier 5). A systematised sensor placement process is a more tractable problem but has not been universally solved (Barrier 6). These barriers can be overcome by model-based simulations capable of running what-if scenarios for the entire critical failure universe affecting a given system in service. Simulating the degradation of the system, as a whole, could offer the level of detailed required by this phase for enabling the integration of the IVHM with Asset design. In this way, the sensor can be placed in the optimum location to maximize the FDI figures and minimize the number of false alarms. Adding to these concerns, the fragmentation of the design of individual part of the asset by suppliers and subcontractors poses a problem for the exchange of information necessary for the development of IVHM algorithms and a centralised IVHM system (Barrier 7). The industry is tackling this problem by developing standards for IVHM systems that should facilitate the exchange of information during their design and even the transfer of data once they are operational.
IVHM systems being difficult to comprehensively test (Barrier 8) is a barrier related to V&V testing. This can be addressed by the adoption of systems engineering practice throughout the IVHM design process, as detailed in Section 3.5. The IVHM system must be one of the most reliable subsystems on the entire vehicle and the IVHM V&V phase should be capable of supporting analysis, test and simulations at the component, subsystem and system level.
Taking into account all of the barriers identified in this paper, and the proposed potential solutions, the future can be viewed in a positive light. While feedback from field experience will take years, most of the barriers can be addressed by good systems engineering practice and tools that are commercially available. What is needed is for industrial leaders to grasp the potential of this new capability and realise its benefits. maritime, and oil & gas (subsea) applications. Octavian has an extensive experience in Integrated Vehicle Health Management, having worked on applied aerospace projects funded by The Boeing Company and BAE Systems as a Research Fellow on his previous appointment with the IVHM Centre at Cranfield University. He is a member of the Prognostics and Health Management Society and the IET.
Dr Manuel Esperon specialises on design of IVHM systems for new and legacy platforms. He has been involved in projects to develop new design methodologies for IVHM, condition monitoring for thermal and electromechanical systems, the development of new datadriven techniques, combining IVHM with Additive Manufacturing, financial analysis of IVHM solutions, and certification of IVHM systems. Prior to joining Cranfield he conducted research on Energy Storage Systems. Dr Esperon has a Master's degree in Mechanical Engineering from the Technical University of Madrid, an MSc in Aerospace Engineering from Brunel University, and a PhD in IVHM from Cranfield University.