8. CHARACTERISTICS

8.1 Overview

It became clear during the creation of the NPDM that there is an enormous amount of data which is covered by the existing legacy standards that is attached to the key ideas of product, anomaly and task (and the relationships between them). The data provides for many characteristic values, varying from the familiar ideas, such as mean time between failure to much more obscure values. Furthermore many of these are provided twice (in the LSAR), once as a requirement (from the assumed single customer) and later as a predicted value (provided by the system/equipment supplier). However in the NPDM, these values can be specified as requirements by different organizations (i.e. applying in a different scenario). Furthermore, taking a view that goes through the life of the product, a measured value (based on fact rather than prediction) may also be provided.

8.2 Description

Given the potential number of such characteristics (see the combined data element lists of the legacy standards), the NPDM takes a more general approach. Firstly a characteristic (or one of many subtypes) is used. In general terms, this defines a name, description and value.

name

Characteristic description

value

measure with unit

Figure 8.1 General form of characteristic

This is then assigned using a characteristic_assignment entity that allows the following to be defined:

∙who provided the value;

∙what scenario does it apply to;

∙is it measured, required, planned, allocated or calculated;

∙to what does it apply.

Figure 8.2 Characteristic assignment

Additionally, some characteristics may be qualified as being mean, maximum or minimum values. This is done by using a qualified_characteristic_assignment entity with an additional attribute that allows the value to be qualified as being a “mean” value for example.

By using this approach the NPDM is kept as an open model which can easily be extended as additional characteristics can be added.

Currently there are many different specific characteristics defined as subtypes of the characteristic entity. If we look at one example to see the way these work, most of the subtypes will become clear.

Mean time between failure is a typical characteristic. It applies to a product (in the NPDM, a product_design_definition or an element) and may be specified as a requirement or as a predicted value by a supplier. In the NPDM this will be a qualified assignment (as “mean”) of the time_between_failure characteristic.

8.3 EXPRESS G Diagrams

CHARACTERISTICS_SCHEMA EXPRESS-G diagram 7 of 8

8.4 EXPRESS Syntax

SCHEMA CHARACTERISTICS_SCHEMA;

REFERENCE FROM ANOMALY_SCHEMA (product_anomaly,

anomaly_in_mission_phase); REFERENCE FROM CORE_MODEL_SCHEMA

(product_version, element, element_relationship,

product_definition_element_relationship, product_definition_relationship, product_design_definition);

REFERENCE FROM DATE_AND_TIME_SCHEMA (date_and_time);

REFERENCE FROM INFORMATION_OBJECT_SCHEMA (external_document);

REFERENCE FROM MEASURE_SCHEMA (measure_with_unit,

time_measure);

REFERENCE FROM PERSON_AND_ORGANIZATION_SCHEMA (organization);

REFERENCE FROM PRODUCT_INSTANCE_SCHEMA (product_instance_definition);

REFERENCE FROM SCENARIO_AND_MAINTENANCE_SCHEMA (scenario,

role, maintenance_level,

maintenance_concept_assignment, product_maintenance_level_association, operating_location);

REFERENCE FROM SUPPORT_RESOURCES_SCHEMA (label,

text_select, identifier);

REFERENCE FROM TASK_SCHEMA (percentage,

task_resource_requirement, task_training,

task);

8.4.1 applicability_switch

TYPE applicability_switch = ENUMERATION OF (no,

not_applicable, yes);

END_TYPE;

8.4.2 characteristic_assignment_type

TYPE characteristic_assignment_type = ENUMERATION OF (actual,

allocated,

calculated,

maximum,

mean,

minimum); END_TYPE;

8.4.8 achieved_availability

The probability, expressed as a percentage, that when used under stated conditions in an ideal support environment, a product will operate satisfactorily at any time. This differs from inherent_availability only in its inclusion of consideration for preventive action. Achieved_availability excludes administrative_and_logistic_delay_time. Achieved_availability may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation.

ENTITY achieved_availability

SUBTYPE OF (availability_characteristic);

END_ENTITY;

8.4.9 administrative_and_logistic_delay_time

The total time, expressed as a unit of measure, that the product is inoperable due to delays in maintenance that is attributable to administration and/or logistics.

ENTITY administrative_and_logistic_delay_time SUPERTYPE OF

(ONEOF(spare_factor,administrative_lead_time,ship_time)) SUBTYPE OF (operational_availability);

END_ENTITY;

8.4.10 administrative_lead_time

The administrative time required to prepare, advertise and award a contract for wholesale supply re-order actions.

ENTITY administrative_lead_time

SUBTYPE OF (administrative_and_logistic_delay_time);

END_ENTITY;

8.4.11 annual_number_of_missions

The estimated or specified mean number of missions per year that the product will be expected to accomplish.

ENTITY annual_number_of_missions

SUBTYPE OF (annual_usage_characteristic);

END_ENTITY;

8.4.12 annual_operation_time

The total hours that the item under analysis is expected to be operated during a calendar year.

ENTITY annual_operation_time

SUBTYPE OF (annual_usage_characteristic);

END_ENTITY;

8.4.13 annual_usage_characteristic

The product operational usage during a calendar year expressed in term of annual_number_of_missions and annual_operation_time.

ENTITY annual_usage_characteristic SUPERTYPE OF

(ONEOF(annual_number_of_missions,annual_operation_time));

END_ENTITY;

8.4.14 authorized_life

The maximum installed life for which a product may be operated.

ENTITY authorized_life

SUBTYPE OF (product_life);

END_ENTITY;

8.4.15 availability_characteristic

The product availability, expressed as a percentage and assigned as either inherent_availability, achieved_availability or operational_availability.

ENTITY availability_characteristic SUPERTYPE OF

(ONEOF(operational_availability,achieved_availability,inherent_av ailablity));

END_ENTITY;

8.4.16 built_in_test_cannot_duplicate

The proportion of Built-In-Test (BIT) indicated malfunctions, expressed as a percentage, that cannot be verified by maintenance personnel when investigating the indicated malfunction.

ENTITY built_in_test_cannot_duplicate SUBTYPE OF (testability_characteristic);

rate : percentage; END_ENTITY;

8.4.17 built_in_test_retest_ok

The proportion of products removed from an assembly due to a BIT indicated malfunction, expressed as a percentage, that subsequently pass all related testing at the next (depth) maintenance level.

ENTITY built_in_test_retest_ok

SUBTYPE OF (testability_characteristic); rate : percentage;

END_ENTITY;

8.4.18 characteristic

A product related characteristic which may be assigned as property_characteristic, monetary_characteristic, time_characteristic, narrative characteristic or point_in_time_characteristic.

ENTITY characteristic ABSTRACT SUPERTYPE OF

(ONEOF(property,narrative_characteristic,time_characteristic,mone tary_characteristic,point_in_time) ANDOR supportability_characteristic);

END_ENTITY;

distribution_form : label; END_ENTITY;

8.4.23 failure_characteristic

A characteristic of a product's reliability specifically related to product failure and assigned as either failure_rate, failure_mode_ratio or time_between_failure.

ENTITY failure_characteristic SUPERTYPE OF

(ONEOF(failure_mode_ratio,time_between_failure,failure_rate)) SUBTYPE OF (reliability_characteristic);

END_ENTITY;

8.4.24 failure_mode_ratio

The proportion of a product's overall failure_rate, expressed as a decimal fraction, which is attributable to the particular failure_mode under analysis of that same product i.e. the probability that the product will fail in the identified mode.

ENTITY failure_mode_ratio

SUBTYPE OF (failure_characteristic);

END_ENTITY;

8.4.25 failure_rate

The total number of failures of a system/product over a specified period, expressed as a floating point, divided by the actual functional operation of the system/product during the specified period.

ENTITY failure_rate

SUBTYPE OF (failure_characteristic); rate : distribution_based_period;

END_ENTITY;

8.4.26 fault_isolation

The probability, expressed as a percentage, that the particular failure_mode of a product can be identified using BIT and assigned to a component of the product at the next lower indenture level in the product_breakdown_structure.

ENTITY fault_isolation

SUBTYPE OF (testability_characteristic); rate : percentage;

END_ENTITY;

8.4.27 fault_isolation_ambiguity_group

A set of items at the same level of indenture having properties such that Built-In-Test (BIT) can determine that at least one item in the set is faulty, but is unable to determine which particular one.

ENTITY fault_isolation_ambiguity_group

8.4.33 money_measure

An amount of money associated with a the given currency.

ENTITY money_measure; money_value : REAL;

8.4.34 narrative_characteristic

A characteristic the value of which is given by description. The interpretation of the characteristic is dependent on its name and the object to which it is assigned.

ENTITY narrative_characteristic

SUPERTYPE OF (narrative_characteristic_with_switch)

SUBTYPE OF (characteristic);

8.4.35 narrative_characteristic_with_switch

A characteristic, the value of which is given by description, together with a switch value defining its validity for the object to which it is assigned. The interpretation of the characteristic is dependent on its name and the object to which it is assigned.

ENTITY narrative_characteristic_with_switch SUBTYPE OF (narrative_characteristic);

applicability : applicability_switch; END_ENTITY;

8.4.36 non_standard_qualifier

The qualifier which is not included in the standard list.

ENTITY non_standard_qualifier;

8.4.37 operation_life

The number of years that the system/equipment is assumed to be operable.

ENTITY operation_life

SUBTYPE OF (operational_availability);

END_ENTITY;

8.4.38 operational_availability

The probability, expressed as a percentage, that when used under stated conditions in an ideal support environment, a product will operate satisfactorily at any time. Operational_availability takes into consideration preventive activities, standby time and administrative_and _logistic_ delay_time.

ENTITY operational_availability

SUPERTYPE OF (ONE OF(standby_time, administrative_and_logistic_ delay_time, operation_life)

SUBTYPE OF (availability_characteristic); END_ENTITY;

8.4.39 package_quantity

The quantity of items that are bought or sold as a unit.

ENTITY package_quantity;

8.4.40 period_characteristic

The length in time of a period.

ENTITY period_characteristic

SUPERTYPE OF (distribution_based_period) SUBTYPE OF (time_characteristic);

duration : time_measure;

8.4.41 point_in_time

A specific moment in time.

ENTITY point_in_time

8.4.42 price_break

ENTITY price_break

SUBTYPE OF (product_price);

WR1: start_price<=end_price;

END_ENTITY;

8.4.43 price_characteristic_assignment

The assignment of a characteristic that is a price.

ENTITY price_characteristic_assignment

SUBTYPE OF (characteristic_assignment);

END_ENTITY;

8.4.44 price_with_minimum_quantity

The minimum quantity of the item to which the price applies.

ENTITY price_with_minimum_quantity SUBTYPE OF (product_price);

count : INTEGER; END_ENTITY;

8.4.45 product_life

The overall life of the product (expressed in units of measure) relating to the product's reliability.

ENTITY product_life SUPERTYPE OF

(ONEOF(total_life,wear_out_life,authorized_life,shelf_life)) SUBTYPE OF (reliability_characteristic);

END_ENTITY;

8.4.46 product_price

The amount of money for which a thing is bought or sold.

ENTITY product_price

SUPERTYPE OF (price_break ANDOR price_with_minimum_quantity) SUBTYPE OF (monetary_characteristic);

8.4.47 property

The assignment of a value and a measurement base to a qualified characteristic.

ENTITY property

SUBTYPE OF (characteristic);

ENTITY spare_factor

SUBTYPE OF (administrative_and_logistic_delay_time);

END_ENTITY;

8.4.53 standby_time

The annual standby time, that a system/equipment is not operating, but is assumed to be operable.

ENTITY standby_time

SUBTYPE OF (operational_availability);

END_ENTITY;

8.4.54 supportability_characteristic

A narrative that describes a product's supportability specifically related to a reliability_characteristic, maintainability_characteristic, availability_characteristic, testability_characteristic, or time_to_perform_task.

ENTITY supportability_characteristic ABSTRACT SUPERTYPE OF

(ONEOF(reliability_characteristic,testability_characteristic,avai lability_characteristic,maintainability_characteristic,annual_usa ge_characteristic));

END_ENTITY;

8.4.55 testability_characteristic

A narrative that describes a characteristic of a product's testability specifically related to detection_level, fault_isolation, built_in_test_cannot_duplicate and built_in_test_retest_ok.

ENTITY testability_characteristic SUPERTYPE OF

(ONEOF(detection_level,built_in_test_retest_ok,fault_isolation,bu ilt_in_test_cannot_duplicate,fault_isolation_ambiguity_group)); END_ENTITY;

8.4.56 time_between_adaptive_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of a maintenance task required to adapt a product to perform a different functional operation to that which it is currently configured to. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_adaptive_maintenance_tasks

SUBTYPE OF (time_between_maintenance_tasks);

END_ENTITY;

8.4.57 time_between_corrective_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of a maintenance task required to restore a product to an acceptable condition. This normally involves a repair or replacement task. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_corrective_maintenance_tasks

SUBTYPE OF (time_between_maintenance_tasks);

END_ENTITY;

8.4.58 time_between_failure

The interval (expressed in units of measure) between failures of the product, where the failure is any primary malfunction of a system, sub system, equipment or component which requires correction by an unscheduled maintenance task. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_failure

SUBTYPE OF (failure_characteristic);

END_ENTITY;

8.4.59 time_between_induced_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of a maintenance task due to an induced malfunction. Induced malfunctions are those induced in the system/equipment under analysis from external sources (ie, other equipment, personnel, etc.). It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_induced_maintenance_tasks

SUBTYPE OF (time_between_maintenance_tasks);

END_ENTITY;

8.4.60 time_between_inherent_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of a maintenance task due to an inherent malfunction. Inherent malfunctions are those malfunctions in the system/equipment under analysis that are assumed to result from internal causes, like manufacturing problems.

ENTITY time_between_inherent_maintenance_tasks

SUBTYPE OF (inherent_maintenance_factor);

END_ENTITY;

8.4.61 time_between_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of any maintenance task required to restore a product to, or maintain it in, a specified condition. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_maintenance_tasks SUPERTYPE OF

(ONEOF(time_between_no_fault_found_maintenance_tasks,time_between _corrective_maintenance_tasks,time_between_induced_maintenance_ta sks,time_between_perfective_maintenance_tasks,time_between_preven tive_maintenance_tasks,time_between_adaptive_maintenance_tasks)); END_ENTITY;

8.4.62 time_between_no_fault_found_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of a maintenance task due to an apparent failure which is subsequently found to be erroneous. Failures include those malfunctions in the system/equipment under analysis indicated by BIT and those detected by inspection or other operator/maintainer action. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_no_fault_found_maintenance_tasks

SUBTYPE OF (time_between_maintenance_tasks);

END_ENTITY;

8.4.63 time_between_overhauls

The interval (expressed in units of measure) between the necessary performance of a maintenance task which is classified as a scheduled overhaul of the product. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_overhauls

SUBTYPE OF (time_between_preventive_maintenance_tasks); END_ENTITY;

8.4.64 time_between_perfective_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of a maintenance task required to optimise the performance of the product, normally associated with software programming. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_perfective_maintenance_tasks

SUBTYPE OF (time_between_maintenance_tasks);

END_ENTITY;

8.4.65 time_between_preventive_maintenance_tasks

The interval (expressed in units of measure) between the necessary performance of a maintenance task which is classified as preventive. Preventive maintenance is that which is designed to realize the inherent reliability capability of the product, often derived through RCM analysis. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_preventive_maintenance_tasks SUPERTYPE OF

(ONEOF(time_between_scheduled_shop_visit,time_between_overhauls)) SUBTYPE OF (time_between_maintenance_tasks);

END_ENTITY;

8.4.66 time_between_scheduled_shop_visit

The interval (expressed in units of measure) between the necessary performance of a maintenance task on the product, within a specified maintenance facility, which is classified as preventive other than overhaul. It may be assigned as "Required", "Predicted" or "Measured", depending on project phase and responsible organisation and labelled as "Minimum", "Mean", or "Maximum". Must be used with an associated Unit of Measure.

ENTITY time_between_scheduled_shop_visit

SUBTYPE OF (time_between_preventive_maintenance_tasks); END_ENTITY;

8.4.67 time_characteristic

A characteristic the value of which is expressed in terms of date and time.

ENTITY time_characteristic

ABSTRACT SUPERTYPE OF (period_characteristic)

SUBTYPE OF (characteristic);

END_ENTITY;

9.FAILURE ANALYSIS (ANOMALY)

9.1Overview

An anomaly is a reason for doing something. There is something about the product that is not how it should be and so work must be done

Traditionally logistics has been driven by the Failure Mode Effects and Criticality Analysis (FMECA). The model does not start with Failure Mode because there are more general reasons for defining tasks than Failure. As an example, the availability of a new software upgrade is not a failure but does give rise to tasks. Hence the name product_anomaly is used simply to indicate that not all is as it should be with the product (e.g. in the previous example, the software is not at the desired release and so is anomalous). However, the model does provide for two specific types of Anomaly: Failure and Damage.

The NPDM treats the propagation of anomalies differently to the legacy standards. Instead of following the logic dictated by the breakdown(s) being used (such as a functional breakdown), it captures the cause-effect relationships. Thus the effects of a given failure can be traced in a manner that reflects the real physics and its equivalent functional impact.

9.2 Description

The obvious starting place is the product_anomaly entity. As explained above there are two specific types of anomaly identified. These are failure_mode and damage. Failure results from a physical problem of the product concerned while damage is externally caused. Damage is treated as a special type of failure_mode. Either of these can also be specified as a failure_mode_from_a_specified_source, which allows the source to be identified. This is to allow for failure_modes defined in standard references, such as the predicted failures for certain types of printed circuit boards.

Now for each failure, we may get some effects. These can be seen as falling into two major categories: local symptoms (for example, increased engine smoke) and other failures (for example, failure in an oil-pump bearing leading to failure of the engine)

9.2.1 Effects

Local symptoms are captured using the effect entity. This allows the effect to be described. Effects are specified as an entity so that the same effect can be shared across multiple failures. (This also allows the query: “show me the failures that have this effect”).

There is no direct link from failure_mode to effect. Instead, there is the mode_effect_assignment entity which allows for an effect to be associated with a failure_mode or with a combination of a failure mode in an operational phase. Thus the fact that the effect of a landing gear failure mode is different during taxi than flight can be captured.

9.2.2 Causal relationships

Traditionally the means to document a failure has been to capture its cause/effect via a functional or hybrid breakdown. The NPDM allows the direct cause/effect relationship to be captured, independent of the breakdown. The NPDM provides a general relationship entity between anomalies. This is then subtyped to be the consequential_failure_relationship. At a simple level the use of the consequential_failure_relationship is as shown below

failure mode 1

failure mode 2

Figure 9.1 One Anomaly Caused by 2 Others

This figure says that failure modes 1 and 2 act as the causes of failure mode 3. In this case failure mode 3 will be specified as a consequential_failure_mode (a subtype of failure_mode). It is possible that failure modes 1 and 2 are primary failures (the start of a causeeffect chain) in which case they can be specified using the primary_failure entity. Alternatively one or both of them could be consequences of other failures.

Primary failures have a cause_description attribute which refers to a separate entity (cause_description) to allow a common set of fundamental causes to be re-used across many failure modes. Examples of such a cause description could be cracking through fatigue or personnel error.

Now life is not always so simple and it may be that a particular failure will occur only if two other failures occur together or if a third failure occurs on its own (not with the first two). This accumulative logic, showing what combinations will occur, is known as roll-up.