IVHM-RD Structure & Flow

The simplest way to relate the stakeholder requirement to the IVHM requirements would be to use just a single HoQ, such as in Figure 5-4, although there would still be the need for a PWC, to compare the stakeholder requirements, and a second HoQ to relate the IVHM requirements to the IVHM enablers.

Figure 5-4 One Single House of Quality

However, this is not best suited to the problem at hand. Having all the stakeholders represented one HoQ creates some problems. First, the HoQ relationship matrix can become very large. Although this will capture how all stakeholder requirements will interact with those of the IVHM (giving a very complete picture) it will take considerable time and effort to populate the form, and may stretch the attention span of the people participating in the data gathering.

Second, the PWC comparison needed to establish the initial ranking would be as large. This would take a long time to complete. Also anyone filling in the PWC would have to have knowledge of all the stakeholders and their

requirements in order to judge which one could be considered more important than another.

Third, is that not all stakeholders will see how their requirements will relate to the IVHM, such is the case with customers[10]. Fourth, the HoQ may be trying to deal with a set of stakeholders which is too diverse.

To engage the stakeholders as requirements capture participants, IVHM-RD split the tool into several HoQs where the different stakeholder groups are paired, and then chained in a logical fashion. This splitting of the HoQ into smaller HoQs make them targeted at the relevant stakeholders.

The IVHM-RD takes into consideration the needs of customer/mission and different aspects of the operation of the UAS and reflects this in the structure of the forms and how they flow into each other – ultimately linking the customer to the IVHM. Below is the general structure and flow for a commercial UA (the issue of the UA being part of the UAS is addressed later in adaptation for the persistent UAS, Section 5.2, page 107)

5.1.3.1 General Structure & Flow for a Commercial UA

The IVHM-RD is split into a single PWC of the Customer Requirements that feeds into a linked series of HoQs. Each HoQ represents different aspects of operating an asset. For the civilian UA being operated as business they are:

 Business House,

 Operations House,

 Maintenance House,

 IVHM House, and

 IVHM Enablers House.

In each house two sets of requirements are compared to each other to establish their relationships. The requirement set that form the columns of one HoQ form the rows of the next, and an importance ranking generated for that set of requirements using the relationship matrix. Figure 5-5 shows the linking of the PWC and the five HoQs and how the information flows from one HoQ to the

next. The flow from the customer requirements, through the HoQs, to the IVHM requirements and enablers allows the knowledge of captured in the forms to be presented in a way where the customer can be linked to the IVHM.

Figure 5-5 Linked HoQs of the IVHM Requirements QFD Process 5.1.3.2 Customer Requirements PWC

This is where the customer/mission requirements are compared with each other to establish the importance ranking of each individual customer requirement. Customer requirements can be based on anything the customer desires and what the mission demands of the UAS. These are often high level requirements and relate to cost, safety, functionality needed to conduct missions, ease of use etc. – all the requirements should be established with the customer of the UAS.

5.1.3.3 Business House

In this HoQ the customer requirements from the PWC are assessed against the business requirements (requirements that relate to use of the UAS as business asset) the relationships established and a numerical value established. Then new importance rankings for the business requirements are calculated and then normalised.

5.1.3.4 Operations House

In this HoQ the Business Requirements from the Business House are assessed against the Operations Requirements (requirements that relate to operation of the UAS), the relationships established and a numerical value established. Then Operations Importance Rankings are calculated from the raw scores and then normalised.

5.1.3.5 Maintenance Houses

In this HoQ the Operations Requirements from the last house are assessed against the Maintenance Requirements of the UAS (requirements that relate to the maintenance of the UAS), the relationships established and a numerical value established. Then Maintenance Importance Rankings are calculated from the raw scores and then normalised.

At this point, a different Maintenance Houses would be needed for each element of the UAS, given the different engineering nature of the elements. The design cases focus on the UA element. The UA is focussed on for the following reasons: it is the part of the UAS which flies, giving any failure more impact (e.g. loss of an expensive aircraft/sensors, public perception); it is one element common to all UAS; creation and population of the forms for the UAS will be sufficient for proof of concept; and SMEs who volunteer for the population will not appreciate filling in multiple similar forms.

5.1.3.6 IVHM Requirements House

In this HoQ the Maintenance Requirements are assessed against the IVHM Requirements (requirements that relate to the IVHM on-board the UA), the

Importance Rankings are calculated from the raw scores then and then normalised.

5.1.3.7 IVHM Enablers House

In this HoQ the IVHM requirements are assed against the IVHM enablers, the relationships established and a numerical value established. Then IVHM Enablers Importance Rankings are calculated from the raw scores and then normalised.

5.2 Design Case Adaptation