D. Summary of Functional Analysis

The functional analysis is the process of translating system-level requirements into de­tailed design requirements- System requirements (discussed in Chapters 3 and 4) are

CO

Ref: Figure, 5-3,3.0

Ref: Figure, 5-3, 1.3

Ref: Figure, 5-3, 2.0

With System Operating in Mode K Check Control Function

G

\

Check

Bearing Validity

G

G

Check Tone Information

G

G

7.0 Localize Fault to Unit Level

7.1 Remove Applicable Unit from System and Replace with Spare

7.2 Transport Faulty Unit to Intermediate Shop

7.3 Isolate Malfunction to Faulty Assembly within Unit

7.4 Remove Faulty Assembly and Replace with Spare

7.5 Accomplish Inplace Repair of Equipment

etc.

7,6 Accomplish Verification of Repair. Conduct Test of Applicable Unit

G

G

7,7, Return Operational Unit to Stock

Ref: Function 7.3 I

Figure 5-6. Maintenance functional-flow diagram.

136

Functional Analysis and Requirements Allocation Chap. 5

Need

To Develop a Transportation Capability

: fr?™??:^ Analysis ^.^;\_::'^.:^.^:^^ ^:*?^:\

III •-:.!:. : :		' ; " :. : : :- '-:-:•: T- . '.'- -. .'•:•:-'-'.		.
Ground Transportation		Airborne Transportation		Waterway Transportation

. _:^_,..............._..._._. ...o

;j^:?:;:;.ii|:^^ '[^Ј^;^^:.^-.^^};\

/•:..."::_;:._r:;o" i¹ (SeSect Airborne Transportation Capabilty) '$&Ј$*$;&•*%

Start Mission

Complete

Mission

Functional Analvsis

Produce

Prime System Elements

Produce

Elements

of Support

Procure

Elements

of Support

System Top-Level Fmictional Flow

Design

Aircraft System

2.0 1.0

Define

System

Requirements

Design

Support Capability

(Qper/Mainl)

Second-Level Functional Flow

4.0

Per form

System Integration Test

5.0

Distribute

System for Consumer Use

9.0

Operate the

System

In User

10_rO

Environment

Maintain

the System

(as Required)

Prepare

Aircraft

for Flight

Prepare Aircraft

for Standby

t

y.o

te The System in User Environ mem

Taxi

Aircraft

for Takeoff

9.4

Takeoff

From

City A

Proceed From City A to City

\

9,6

Land

at City 8

9.7

Perform

Aircraft Checkout

Third-Level Functional

nctional Flow 1

•^

Ref.

Proceed From to City B

-	'.J. L	*	7— '.Ј	H	f.j.j	p	-f.j.i
	Check Cnnnnjunication Subsystem		Coniaci Control Tower		Contact Control Tower City B		Receive Landing Instructions
	1

Maintenance Flow

eic.

Figure 5-7. Evolutionary development of functional requirements.

138

Functional Analysis and Requirements Allocation Chap. 5

A. Reliability Allocation⁶

After an acceptable reliability factor (e.g., probability of survival) or failure rate has been established for the system, it must be allocated among the various subsystems, units, assemblies, and so on. The allocation commences with the generation of a reli­ability block diagram. The block diagram is a further extension of the functional flow diagrams presented in Figures 5-3 and 5-4. The intent is to develop a reasonable ap­proximation of those elements or items that must function for successful operation of the system. To the extent practicable, the diagram should be structured so that each block represents a functional entity that is relatively independent of neighboring blocks.

In the development of a block diagram, items that are predominantly electronic in function are noted as electronic elements and items that are basically mechanical are identified accordingly. Item redundancy contemplated at this stage of system planning should be illustrated along with any planned provisions for alternative operating mode capability.

Figure 5-10 is a simplified reliability block diagram and the progressive expansion of such from the system level down as design detail becomes known. Generally, levels I and II are available through conceptual design activity, while levels III and on are defined in preliminary system design.

Referring to the figure, the reliability requirement for the system (e.g., X, R* MTBF) is specified for the entire network identified in Level I, and an individual re­quirement is specified for each individual block in the network. For instance, the reli­ability of block 4, Function X_y may be expressed as a probability of survival of 0,95 for a 4-hour period of operation at Level L Similar requirements are specified for blocks 1, 2, 3, and 5. These, when combined, will indicate the system reliability, which in turn is evaluated in terms of the overall requirement.

Block diagrams are generated to cover each of the major functions identified in Figure 5-3. Success criteria (go/no-go parameters) are established and failure rates (X) are estimated for each block, the combining of which provides an overall factor for a series of blocks constituting a function or subfunction. Depending on the function, one or more of these diagrams can be related to a physical entity such as Unit A in Figure 5-3, or an assembly of Unit A. The failure-rate information provided at the unit/assembly level represents a reliability design goal. This, in turn, represents the anticipated fre­quency of corrective maintenance that is employed in the determination of logistic re­source requirements.

The approach used in determining failure rates may vary depending on the maturity of system definition. Failure rates may be derived from direct field and/or test experience covering like items, reliability prediction reports covering items that are similar in na­ture, and/or engineering estimates based on judgment. In some instances, weighting factors are used to compensate for system complexity and environmental stresses.

t

«

⁶ An in-depth coverage of reliability allocation is not intended nor is it practical within the confines of this book. The review of additional text material is recommended for students desiring comprehensive cov­erage of the subject matter. Refer to Appendix H,

ic ,> '

fci^fe

140

Functional Analysis and Requirements Allocation Chap. 5

2. Identify the areas which are new and where design information is not available. Assign complexity weighting factors to each functional block. Complexity factors may be based on an estimate of the number and relationship of parts, the equipment duty cycle, the mode of operation and criticality of the path, whether an item will be subjected to temperature extremes, and so on. That portion of the system reli­ability requirement which is not already allocated to the areas of known design is allocated using the assigned weighting factors.

The end result should constitute a series of lower-level values which can be com­bined to represent the system reliability requirement initially specified (i.e., MTBF of 450 hours for System XYZ). The combining of these values is facilitated through the application of a reliability mathematical model,

A reliability mathematical model is developed to relate the individual "block" reliability to the reliabilities of its constituent blocks or elements. The procedure simply consists of determining a mathematical expression that represents the probability of sur­vival for a small portion of the proposed configuration. Multiple applications of this process will eventually reduce the original complex system to an equivalent serial con­figuration. It is then possible to represent the system with a single probability statement. Some of the mathematical relationships used in this instance were described in Section 2.1.

When allocating a system level requirement (i.e., MTBF of 450 hours), one should construct a simplified functional breakdown as illustrated in Figure 5-11. The diagram must reflect series-parallel relationships.

Initially, failure rates are identified for items of known-design and are deducted from the overall system requirement. A complexity factor may be established for each of the remaining items.⁷ The complexity factors are used to apportion failure rates to the next lowest level and on down. As a check, failure rates at the assembly level are totaled to obtain the unit failure rate, and unit failure rates support the system failure rate (note that Units A, B, and C represent a series operation). The MTBF is usually assumed to be the reciprocal of the failure rate, and the reliability (ft) of the system or unit may be determined from Equation (2.5) or the nomograph in Figure 2-3.

Referring to Figure 5-11, a reliability block diagram showing the functional rela­tionship of four elements (a, fc, c, and d) illustrates the ⁴'makeup" of assembly 2. The mathematical expression for the four elements is

(5.1)

Using the general relationships in Equation (2.5), reliability factors and failure rates can be determined. In this instance, the total failure rate for Assembly 2 should not exceed 0.00155.

Review of the equipment breakdown configuration illustrated in Figure 5-11 in­dicates a top-level system requirement supported by factors established at the unit level and on down. Unless otherwise specified, the requirements at the unit level may be

In Figure 5-11, complexity factors are assumed for all items.

142

Functional Analysis and Requirements Allocation Chap. 5

serve as design criteria. For instance, the engineer responsible for Unit B shall design Unit B such that the failure rate (X) shall not exceed 0,001866. As design progresses, reliability predictions are accomplished and the predicted value is compared against the requirement of 0.001866, If the predicted value does not meet the requirement (i.e., higher failure rate or lower MTBF), then the design configuration must be reviewed for reliability improvement and design changes are implemented as appropriate.

The allocated factors not only provide the designer with a reliability criterion, but serve as an indicator of the frequency of corrective maintenance due to anticipated equip­ment failure. Assume that System XYZ is projected into an operational posture similar to the one described for the vehicular communication system in Chapter 3, and that the total system operating time per year is 60,000 hours for a 10-year period. The expected quantity of system maintenance actions due to failure is

expected maintenance actions =

total operating hours per year MTBF

(5.2)

or

expected maintenance actions =

60,000 450

133/year

Assuming that each of the units is operating or energized on a full-time basis when the system is operational, then the quantity of expected maintenance actions for each unit can be determined from Equation (5.2). The results are 15 maintenance actions per year for Unit A, 112 maintenance actions per year for Unit 6, and 6 maintenance actions per year for Unit C The frequency of maintenance is a necessary input in the determi­nation of logistic resource requirements (material and cost) for a system or equipment.

B. Maintainability Allocation

The process of translating system maintainability requirements (e.g., MTBM, Met, Mpt, MMH/OH) into lower-level design criteria is accomplished through maintainability al­location. The allocation requires the development of a simplified functional breakdown as illustrated in Figure 5-11. The functional breakdown is based on the maintenance concept, functional analysis data, and a description of the basic repair policy—whether a system is to be repaired through the replacement of a unit, an assembly, or a part.

For the purpose of illustration, it is assumed that system XYZ must be designed to meet an inherent availability requirement of 0.9989, a MTBF of 450, and a MMH/OH (for corrective maintenance) of 0.2 and a need exists to allocate Met and MMH/OH to the assembly level.⁸ The Met equation is

— MTBF(1 - A:

A-,

Met = ⁱ

(53)

¹MTBM and Mpt may be allocated on a comparable basis as MTBF and Met, respectively.

144

Functional Analysis and Requirements Allocation Chap. 5

The estimated value of C_f for each unit is entered in column 7, andjhe sum of the contributions for all units can be used to determine the overall system's Met as

— EC, 1.077

- 0.485

(5.4)

.3

:

•"

In Table 5-1, the calculated Met for the system is within the requirement of 0.5 hour. The Met values for the units provide corrective maintenance downtime criteria for design, and the values are included in equipment design specifications^

Once allocation is accomplished at the unit level, the resultant Met values can be allocated to the next lower equipment indenture item. For instance, the 0.4-hour Met value for Unit B can be allocated to Assemblies 1,2, and 3, and the procedure for allocation is the same as employed in Equation (5.4). An example of allocated values for the assemblies of Unit B is included in Table 5-2.

Table 5-2. unit b allocation

1	2	3	4	5	6	7
Assembly 1 Assembly 2 Assembly 3	1 1 1	0.116 1.550 0.200	0.116 1.550 0.200	6% 83% 11%	0.5 0.4 0.3	0.058 0.620 0.060
Total			1.866	100%		0.738
ECO 738 Met for Unit B .= -~ = 7^77 = 0.395 hour (Requirement: 0.4 hour) Ј Cy 1.866

The Met value covers the aspect of elapsed or clock time for restoration actions. Sometimes this factor, when combined with a reliability requirement, is sufficient to establish the^necessary maintainability characteristics in design. On other occasions, specifying Met by itself is not_adequate since there may be a number of design ap­proaches which willjneet the Met requirement but not necessarily in a cost-effective manner. Meeting a Met requirement may result in an increase in the skill levels of personnel accomplishing maintenance actions, increasing the quantity of personnel for given maintenance functions, and/or incorporating automation for manual operations. In each instance, there are costs involved; thus, one may wish to specify additional con­straints such as the skill level of personnel at each maintenance level and the maintenance manhours per operating hour (MMH/OH) for significant equipment items. In other words, a requirement may dictate that an item be designed such that it can be repaired within a specified elapsed time with a given quantity of personnel possessing skills of a certain level. This will influence design in terms of accessibility, packaging schemes, handling requirements, diagnostic provisions, and so on, and is perhaps more meaning­ful in terms of designing for logistic support.

The factor MMH/OH is a function of task complexity and the frequency of main­tenance. The system-level requirement is allocated on the basis of system operating hours, the anticipated quantity of maintenance actions, and an estimate of the number of manhours per maintenance action. Experience data are used where possible.

146

Functional Analysis and Requirements Allocation Chap. 5

-r

2. Self-test thoroughness for the system (using the built-in test capability) shall be 95% or better.

3. Personnel skill levels at the organizational level of maintenance shall be equivalent to grades or below.

4. The maintenance facility at the intermediate level shall be designed for a minimum of 75% utilization,

5. The transportation time between the location where organizational maintenance is accomplished and the intermediate maintenance shop shall not exceed 48 hours.

6. The turnaround time in the intermediate maintenance shop shall be 5 days (or less), and 15 days (or less) in the depot maintenance facility.

7. The probability of spares availability at the organizational level of maintenance shall be at least 90%.

In essence, in defining system operational requirements and the maintenance con­cept (described in Chapters 3 and 4), system supportability factors must be determined along with performance parameters. These factors, established at the system level, may be allocated to the extent necessary to influence design activities.

D. Allocation of Economic Factors

Using an approach similar to that described in previous sections, cost factors may be allocated as appropriate to system needs. If the ultimate product is to be cost-effective, it may be desirable to assign cost targets for various equipment items. For instance, an objective might be to design System XYZ such that the unit system cost is $500,000, based on a production quantity of 300 and an operational life of 10 years. Unit cost constitutes total life-cycle cost (to include research and development, production, and operation and maintenance cost) divided by the quantity of systems. This cost factor, specified at the top level, can be apportioned to lower equipment indenture levels as cost targets for design. Cost targets combined with reliability (or equivalent) requirements may create a boundary situation for design as illustrated in Figure 2-34. In other words, one can design to a cost.