B2.0  FAILURE ANALYSIS (ANOMALY) FUNCTION

B2.1  Failure Analysis (Anomaly) Diagrams

B2.2  Failure Analysis (Anomaly) Express Definitions

B2.2.1  Definitions
REFERENCE FROM Task

(logistics_task,
criticality,
period_measure,
occurence_rate);

REFERENCE FROM CoreModel

(label);

REFERENCE FROM InfoObj

(text_select);

REFERENCE FROM Lsa

(scenario,
product_aspects,
scenario_or_role);

USE FROM document_schema

(document);

USE FROM measure_schema

(time_measure_with_unit);

B2.2.1.1  Detection_method_category
TYPE detection_method_category = ENUMERATION OF

(automatic_test_equipment,
external_equipment,
human_detection,
manual_test_equipment,
other,
visual_inspection);

END_TYPE;

B2.2.1.2  Probability
TYPE probability = REAL;
WHERE

WR1: {1.0<=SELF<=0.0};

END_TYPE;

B2.2.1.3  Product_anomaly_or_anomaly_in_mission_phase
TYPE product_anomaly_or_anomaly_in_mission_phase = SELECT

(anomaly_in_mission_phase,
product_anomaly);

END_TYPE;

B2.2.1.4  Safety_hazard_severity
TYPE safety_hazard_severity = ENUMERATION OF

(catastrophic,
critical,
marginal,
minor,
negligible,
none);

END_TYPE;

B2.2.1.5  Task_assignment_logic
TYPE task_assignment_logic = ENUMERATION OF

(corrective,
operational,
other,
perfective,
preventive);

END_TYPE;

B2.2.1.6  And_consequential_failure_relationship
A consequential failure (commonly also known as Failure Effect) can be caused as a direct consequence of a primary failure, or as a conditional consequence which only materializes when two or more primary failures occur. In the case that a consequential failure is only caused when two or more primary failures have occurred, "and_consequential_failure_relationship" links two or more failure modes which must occur before the consequential failure occurs.

ENTITY and_consequential_failure_relationship
SUBTYPE OF (roll_up_relationship);
END_ENTITY;

B2.2.1.7  Anomaly_in_mission_phase
A consequential failure which occurs as a result of a primary failure may be different depending on the mission phase in which the primary failure occurs. "anomaly_in_mission_phase" links different failure modes to specific mission phases.

ENTITY anomaly_in_mission_phase;

phase: mission_phase;
failure: product_anomaly;

END_ENTITY;

phase: The assignment of mission phase to an anomaly where the mission phase is relevant to the anomaly.
failure: Assignment of a failure to a mission phase.

B2.2.1.8  Cause_description
A description of the mechanisms which cause a primary failure. This allows the description of a cause which is not specific for a particular primary_failure such as "fatigue."

ENTITY cause_description;

name: label;
description: text_select;

END_ENTITY;

B2.2.1.9  Compensating_provision
Design provisions and/or operator actions which circumvent or mitigate the effect of a failure.

ENTITY compensating_provision
SUPERTYPE OF (operator_action ANDOR design_provision);

name: label;
description: text_select;

END_ENTITY;

B2.2.1.10  Consequence_probability
ENTITY consequence_probability;

risk: REAL;

END_ENTITY;

B2.2.1.11  Consequential_failure_mode
A failure mode which has been directly or indirectly caused by the occurrence of a primary failure.

ENTITY consequential_failure_mode
SUBTYPE OF (failure_mode);
INVERSE

causes: SET[1:?] OF consequential_failure_relationship FOR relating_product_anomaly;

END_ENTITY;

B2.2.1.12  Consequential_failure_relationship
Link between primary failure mode(s) and consequential failure mode(s).

ENTITY consequential_failure_relationship
SUBTYPE OF (product_anomaly_relationship);

probability: OPTIONAL consequence_probability;

SELF\product_anomaly_relationship.relating_product_anomaly: consequential_failure_mode;
END_ENTITY;

B2.2.1.13  Damage
Type of failure mode which has not been caused by an inherent property of the product but by external influence. (usually environment or human).

ENTITY damage
SUBTYPE OF (failure_mode);
END_ENTITY;

B2.2.1.14  Design_provision
A description identifying design provisions which circumvent or mitigate the effects of the failure. A record of the true behavior of the item in the presence of an internal malfunction or failure. Features of the design at any indenture level that will nullify the effects of a malfunction or failure, control or deactivation system items to halt generation or propagation of failure effects, or activate backup or standby items or systems. Redesign compensating provisions include:

a. Redundant items that allow continued and safe operation.
b. Safety or relief devices such as monitoring or alarm provisions which permit effective operation or limit damage.
c. Alternate models of operation such as backup or standby items or systems.

ENTITY design_provision
SUBTYPE OF (compensating_provision);

uses: SET [0:?] OF product_aspects;

END_ENTITY;

uses: Reference between the compensating design provision and the definition of the product quoted as being the designed device (fail safe device, standby system etc.)

B2.2.1.15  Detection_method
The method(s) by which occurrence of a specific failure mode is detected by the operator or maintenance technician. Describes warning devices, if applicable, and other indications which make evident to the operator or technician that a system/equipment has malfunctioned or failed. If no indication exists, states if the undetected failure will jeopardize the mission objectives or personnel safety, and if the undetected failure allows the system to remain operational in a safe state, explores possible resulting second failure situations. Proper correlation of a system malfunction or failure may require identification of normal, as well as abnormal indications. Normal indications are those that are evident to an operator when the system is operating normally. Abnormal indications are those that are evident to the operator when the system has malfunctioned or failed.

ENTITY detection_method;

category: detection_method_category;
uses: OPTIONAL SET [1:?] OF product_aspects;
description: text_select;

END_ENTITY;

category: Category of detection method types to be decided on a project-specific basis.

B2.2.1.16  Effect
Engineering effect of a failure mode on the highest level procured product. Not to be confused with the consequential_failure_mode. The chain of events such as the following: Split Pin breaks, Nut loosens, Nut falls off, Bearing falls out, Wheel falls off. It is represented by a network of consequential_failure_modes. However, at all stages, the effect on the procured item (vehicle) i.e., loss of control of vehicle, vehicle leaves road, is represented by this entity.

ENTITY effect;

name: label;

END_ENTITY;

B2.2.1.17  Failure_mode
Description of the inability of the product to conform to one of its specified or expected parameters when this failure to conform is due to a breakage or fault and which is caused by an inherent property of the product or by a product anomaly of another product.

ENTITY failure_mode
SUPERTYPE OF (ONEOF(consequential_failure_mode,primary_failure) ANDOR damage ANDOR failure_mode_from_specified_source);

compenseted_by: SET [0:?] OF compensating_provision;
detected_by: SET [1:?] OF detection_method;

END_ENTITY;

compenseted_by: If the failure mode itself can be compensated for, then this is the link between the failure mode which is compensated and the compensating provision.
detected_by: The detection method(s) expected to notify the occurrence of a failure to the user of the product.

B2.2.1.18  Failure_mode_from_specified_source
Link to a (usually) generic source document used in determining the failure mode, where the failure mode has not been defined uniquely and for the first time.

ENTITY failure_mode_from_specified_source
SUBTYPE OF (failure_mode);

source: document;

END_ENTITY;

source: The document or reference from which the failure mode and associated data was obtained.

B2.2.1.19  Mission
Definition of the mission which is to be performed by the (usually) highest level procured product.

ENTITY mission;

name: label;
description: text_select;
in_scenario: scenario;
mean_duration: time_measure_with_unit;

END_ENTITY;

name: The word or group of words by which the mission is referred to and which serve to differentiate between different mission profiles within a project. (E.g., Transport, Recovery, Reconnaissance).
description: A clear text description of the mission.
in_scenario: The situation and/or usage profile and/or customer for which the mission is applicable.
mean_duration: The statistical average duration of a mission in accordance with the project-specific definition of the mission.

B2.2.1.20  Mission_phase
Definition of a part of a mission. Mission phases are mutually exclusive and usually time segments of a mission. The sum of all mission phases of a mission is the mission itself.

ENTITY mission_phase;

id: label;
name: label;
description: OPTIONAL text_select;
phase_time: OPTIONAL time_measure_with_unit;
of_mission: mission;

END_ENTITY;

id: The identification of the mission phase. Usually a coded item assigned on a project-specific basis.
name: The word or group of words by which the mission phase is referred to.
description: A clear text description of the mission phase.
phase_time: The elapsed duration of the mission phase.
of_mission: The mission of which the phase is a part.

B2.2.1.21  Mode_effect_assignment
The assignment of an effect to a given anomaly.

ENTITY mode_effect_assignment;

assigned_effect: effect;
assigned_to: product_anomaly_or_anomaly_in_mission_phase;
probability: OPTIONAL probability;
criticality: criticality;
compensated_by: SET [0:?] OF compensating_provision;
severity: safety_hazard_severity;

END_ENTITY;

assigned_effect: The effect being assigned to a failure_mode.
assigned_to: Selection to decide whether the effect is assigned directly to a failure_mode or to a failure_mode/mission_phase combination.
probability: The probability that the effect will materialize when the failure_mode has occurred.
criticality: Link to a criticality which is applicable to the failure_mode/effect combination.
compensated_by: Link to a compensating_provision which is applicable to the failure_mode/effect combination.
severity: The severity of an anomaly for a given mission phase.

B2.2.1.22  Operator_action
A narrative description describing operator actions to circumvent or mitigate the effect of the postulated failure. Describes the compensating provision that best satisfies the indication(s) observed by an operator when the failure occurs, and the consequences of any probable incorrect action(s) by the operator in response to an abnormal indication.

ENTITY operator_action
SUBTYPE OF (compensating_provision);
END_ENTITY;

B2.2.1.23  Or_consequential_failure_relationship
A consequential failure (commonly also known as Failure Effect) can be caused as a direct consequence of a primary failure, or as a conditional consequence which only materializes when two or more primary failures occur. In the case that a consequential failure is caused when either one or more primary failures have occurred, "or_consequential_failure_relationship" links the two or more failure modes which may be the causes of the consequential failure.

ENTITY or_consequential_failure_relationship
SUBTYPE OF (roll_up_relationship);
END_ENTITY;

B2.2.1.24  Other_item_effect
Pointer to an anomaly in another item which is associated with a product anomaly, but not necessarily directly caused by it.

ENTITY other_item_effect
SUBTYPE OF (product_anomaly_relationship);
END_ENTITY;

B2.2.1.25  Preventive_task_assignment
The assignment of a task to a predicted anomaly in order to prevent the occurrence of the anomaly.

ENTITY preventive_task_assignment
SUBTYPE OF (task_anomaly_assignment);

frequency: period_measure;

END_ENTITY;

frequency: The frequency with which the task should be performed.

B2.2.1.26  Primary_failure
Inability of an item to fulfill its required function(s) due to breakage caused by an inherent property of the item. Breakage here is not only in a classical mechanical sense, but may be also (e.g.) a discontinuity in a computer program.

ENTITY primary_failure
SUBTYPE OF (failure_mode);

cause: cause_description;

END_ENTITY;

cause: Root cause of a primary failure.

B2.2.1.27  Product_anomaly
Undesired condition of an item. May be due to breakage (failure mode) damage (damage mode) or other causes that require a task to be performed. (e.g., item is in wrong position, item has wrong color, item has no fuel).

ENTITY product_anomaly
SUPERTYPE OF (failure_mode);

of_product_aspects: SET [1:?] OF product_aspects;
id: label;
description: text_select;
remarks: OPTIONAL text_select;
anomaly_frequency: occurence_rate;

END_ENTITY;

of_product_aspects: Links the product_anomaly to a product aspect.
id: The identification of the product anomaly.
description: A clear text description of the product anomaly.
remarks: Clear text remarks applicable to the product_anomaly.

B2.2.1.28  Product_anomaly_relationship
Relationship of a product anomaly to other product anomalies of either the same item or others. The other product anomalies may be either consequential (caused by the original anomaly) or related (go hand-in-hand with the original anomaly)

ENTITY product_anomaly_relationship
SUPERTYPE OF (ONEOF(consequential_failure_relationship,other_item_effect));

relating_product_anomaly: product_anomaly;
related_product_anomaly: SET [1:?] OF product_anomaly;
reason: text_select;

END_ENTITY;

relating_product_anomaly: The anomaly which is caused by another anomaly.
related_product_anomaly: The anomaly which is the cause of another anomaly.

B2.2.1.29  Roll_up_relationship
ENTITY roll_up_relationship

ABSTRACT SUPERTYPE OF (ONEOF(or_consequential_failure_relationship,and_consequential_failure_relationship,xor_consequential_failure_relationship));
first_relationship: product_anomaly_relationship;
second_relationship: product_anomaly_relationship;

WHERE

WR1: first_relationship.relating:=: second_relationship.relating;

END_ENTITY;

B2.2.1.30  Task_anomaly_assignment
The assignment of a task to an anomaly, indicating that the task is defined as a consequence of the anomaly.

ENTITY task_anomaly_assignment
SUPERTYPE OF (preventive_task_assignment);

applies_to: product_anomaly;
applies_in: OPTIONAL scenario_or_role;
task: logistics_task;
logic: task_assignment_logic;

END_ENTITY;

applies_to: The anomaly to which the task relates.
applies_in: The scenario or role in which the task_anomaly_assignment is effective.
logic: The reasoning for assigning the task to the anomaly.

B2.2.1.31  Xor_consequential_failure_relationship
A consequential failure (commonly also known as Failure Effect) can be caused as a direct consequence of a primary failure, or as a conditional consequence which only materializes when two or more primary failures occur. In the case that a consequential failure is caused when only one of two or more primary failures have occurred, "or_consequential_failure_relationship" links the two or more failure modes which may be the causes of the consequential failure.

ENTITY xor_consequential_failure_relationship
SUBTYPE OF (roll_up_relationship);
END_ENTITY;