Fault state - Business perspective

Fault state - Overview

This exchange enables the transmission of the data exchange set (DEX) Fault States

The Fault State Dex deals with how a product can or may degrade in its functions. It is usual for the set of fault states to be derived from a formal analysis process such as Failure Modes and Effects and Criticality Analysis (FMECA)

The analysis is an iterative process, potentially changing at each stage of the products life cycle. The initial analysis ideally conducted as early as possible in the product life cycle.

The formal analysis, such as FMECA, is conducted with the following objectives:

• Feedback of required changes to design;
• Evidence of safety and reliability have been given due consideration in the product design;
• Identification of support drivers, which are the justification for the generation of maintenance task descriptions.

Fault state analysis result - Information Content

Administrative and context information

General administrative information includes all the information to uniquely identify and describe the result from a specific formal fault state analysis. This would be comparable to the header information in a FMECA worksheet. This includes:

• Identification of an individual revision of the fault state analysis result;
• Status such as draft, issued etc;
• Identification of the top item product to which the fault state analysis result relates;
• Author;
• Applicable operational context(s);
• Dates;
• Approval(s).

Details

Product breakdown

Each record in the detail section of a fault state analysis result identifies the element in a product breakdown (system, functional, assembly etc) to which a failure mode applies.

Failures

Each breakdown element considered in the DEX may have one or more assigned failures modes. The following information should be provided for each failure mode identified:

• Failure mode description and characterization;
• Consequences (Failure effects);
• Criticality assessment.

Each failure mode is characterized by:

• Identification;
• Description;
• Classification;
• Predictability;
• Detection method;
• Contexts such as operational state, mission phase etc.

Typical failure mode classes are (based on Moubray - 'Reliability centered maintenance'):

• Deterioration
  • Fatigue
  • Corrosion
  • Abrasion
  • Erosion
  • Evaporation
  • Degradation of insulation
• Lubrication failure
  • Lack of lubrication
  • Failure of lubrication
• External effect
  • Contamination
  • Dirt
  • Accident
  • Sabotage
  • Adverse environmental conditions
• Disassembly
  • Failure of welds, soldered joints or rivets due to fatigue
  • Failure of threaded components such as bolts, electrical connections or pipefittings
  • Loosening of threaded components such as bolts, electrical connections or pipefittings
  • Failure of locking mechanisms such as split pins, locking wire etc
• Human error
  • Increase in desired performance

Failure mode predictability may be represented by:

• Qualifiers
  • Highly predictable
  • Unpredictable
• Value of P-F Interval (interval between the point when a potential failure becomes detectable and the point at which it degrades into a functional failure)
• Value of ß parameter of Weibull distribution

NOTE    Failure mode predictability describes the relationship between the product design's failure characteristics and an individual product's failure characteristics. For example the product design mean time to failure by wear out is 5000 hours. If every individual product failed between 4900 and 5100 hours this would be described as a highly predictable failure mode; if however every individual product failed in the range 1000 to 9000 hours this would be described as an unpredictable failure mode.

Typical detection methods are:

• Alarm
• Built in test
• Non-destructive examination
• Vibration analysis
• Particle analysis
• Chemical analysis
• Spectrographic analysis
• Visual
• Audible
• Olfactory

The identification of the context in which a failure mode is predicted to occur, may be defined as one or more of the following:

• Operating state
  • Duty
  • Standby
  • Storage
• Environment
  • Arctic
  • Desert
  • Tropical
• Mission phase
  • Start up
  • Take off
  • Cruise
  • Landing
  • Shut down

Consequences may be characterized by:

• Description
• Classification
• Reference to the affected function, system etc

Typical classes of relationships between the failure mode and its consequences are:

• Cause effect
  • Primary / Secondary
  • Failure effect
    • Local effect
    • Next higher effect
    • End effect
• Boolean
  • And
  • Or
  • Xor

Criticality indicator is based on the combination of the severity of faults and the likelihood of a cause, fault or consequence occurring

Typical classifications of severity are:

• Safety [source: def stan 02-45]
  • Death
  • Serious injury
  • Injury
  • Treatment
• Environmental [source: Rolls-Royce]
  • Contamination of land
  • Ground-water pollution
  • Depletion of non-renewable resources
  • Noise nuisance
• Operational [source: def stan 02-45]
  • Loss of platform
  • Loss of mission
  • Availability less than specified
  • Minimal risk to mission or platform
• Non-operational [source: def stan 02-45]
• Economic [source: def stan 02-45]
  • Catastrophic
  • Critical
  • Marginal
  • Negligible
• Hidden / evident [source: def stan 02-45]

Typical representations of likelihood are:

• Probability

  • EXAMPLE    50%

• Frequency

  • EXAMPLE    < 10.000 hrs, > 200 landings, < 4 years

• Qualitative [source: def stan 02-45]
  • Frequent
  • Probable
  • Occasional
  • Remote
  • Improbable.

NOTE    Criticality code can be derived from the combination of severity and likelihood.

Notes can be made for any failure mode record. Examples of notes are additional information on product changes or tasks required to manage the effects of the failure mode under consideration.

Definition of fully acceptable, degraded or fault state

Each element in a product breakdown may have a range of values defining its degraded or fault state, i.e. state definitions with related properties. Examples of values that can be used to determine the respective state are:

• Temperature
• Speed
• Pressure.

Fault state - Implementation details

Model overview

This section is a detailed description on how to implement a typical fault state analysis result in PLCS, using defined PLCS capabilities and PLCS reference data.

This implementation may be further tailored by specific parties, firstly by extending the reference data library, and secondly by introducing new relationships between entities available in the schema for the Fault states DEX, which are not used in this basic implementation of the DEX.

The implementation details are organized in accordance with the section 'Fault state analysis result - Information Content' above.

An overview of the capabilities used by this DEX is shown in figure 1 below.

Basic constructs

A fault state analysis result is an actual product and is therefore represented as a Product_as_realized as described in the C011: representing_analysis_result capability. The actual fault state analysis result (Product_as_realized) is a realization of a Part representing all editions of the fault state analysis result. The Part should be classified as [Fault_state_analysis_result]
Error RDL1: The class Fault_state_analysis_result does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
and the Product_as_realized should be classified as [Revision]
Error RDL1: The class Revision does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

Representation of general administrative and context information

The representation of the general administrative and context information of a fault state analysis result, is based on the constructs described within the "Representing context information" section of the C011: representing_analysis_result capability, along with some additional reference data.

The general administrative information is represented as follows:

• Identification of an individual revision - of a fault state analysis result is represented as firstly, an Identification_assignment being assigned to the Product_as_realized representing the revision of the fault state analysis result, and secondly, an Identification_assignment being assigned to the Part entity representing all revisions of the fault state analysis result. The Identification_assignment being assigned to the Part should be classified as [AnalysisResultIdentification]
  Error RDL1: The class AnalysisResultIdentification does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  and the Identification_assignment being assigned to the Product_as_realized should be classified as [Revision_identification]
  Error RDL1: The class Revision_identification does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .

  NOTE    For more details on how to represent the identification of an analysis result see the "Identification" section of the C011: representing_analysis_result capability.

• Status - of the revision of the fault state analysis result is represented as a State as described in the "Status" section of the C011: representing_analysis_result capability. The State representing the status should be assigned to the Product_as_realized representing the revision of the fault state analysis result. The types of states that a fault state analysis result may be in are defined as classes of State_definition. Examples of classes representing the status of a fault state analysis result are "Draft" (urn:plcs:rdl:std:Draft), "Reviewed" (urn:plcs:rdl:std:Reviewed) and "Final" (urn:plcs:rdl:std:Final).
• The top item product to which the fault state analysis relates - is represented as either a Part or a Breakdown_element, as described in the "Related product" section of the C011: representing_analysis_result capability. The product is referenced by its identifier which in turn could be classified as e.g. [Part_code]
  Error RDL1: The class Part_code does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , [LCN_code]
  Error RDL1: The class LCN_code does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  or [Name_identification]
  Error RDL1: The class Name_identification does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  depending on the context. The relationship between the Part representing the fault state analysis result and the Part representing the product under consideration is established using the Product_relationship entity. The Product_relationship should be classified as [ContextItem]
  Error RDL1: The class ContextItem does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .
• Author - is represented as a Person, Person_in_organization or as an Organization as described in the "Involved parties" section of the C011: representing_analysis_result capability. The Organization_or_person_in_organization_assignment should be classified as [IssuedBy]
  Error RDL1: The class IssuedBy does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .
• Applicable operational contexts - The identification of the context for which the fault state analysis result is valid, may be defined as one or more of the following:
  • Operating state - represented as State_definition as described in the C007: representing_state_type capability. The Applied_state_definition_assignment should be classified as [Operating_state]
    Error RDL1: The class Operating_state does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    , and the State_definition should be classified in accordance with the defined state. Typical values include [Operating]
    Error RDL1: The class Operating does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    , [Storage]
    Error RDL1: The class Storage does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    , "Standby" (urn:plcs:rdl:std:Standby) and [ColdShutDown]
    Error RDL1: The class ColdShutDown does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    .
  • Environment - as described in the "Environment" section of the C011: representing_analysis_result capability. The Applied_state_definition_assignment representing the operational context should be classified as [OperatingEnvironment]
    Error RDL1: The class OperatingEnvironment does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    .
  • Mission phase - represented as State_definition as described in the C007: representing_state_type capability. The Applied_state_definition_assignment should be classified as [Mission_phase]
    Error RDL1: The class Mission_phase does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    , and the State_definition should be classified in accordance with the defined state. Typical values include [Start_up]
    Error RDL1: The class Start_up does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    [Take_off]
    Error RDL1: The class Take_off does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    , [Cruise]
    Error RDL1: The class Cruise does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    , [Landing]
    Error RDL1: The class Landing does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    and [Shut_down]
    Error RDL1: The class Shut_down does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    .
• Dates - are represented as Calendar_date or Date_time as described in the "Dates" section of the C011: representing_analysis_result capability. The Date_or_date_time_assignment should be classified. A typical value is [DateOfIssue]
  Error RDL1: The class DateOfIssue does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .
• Approvals - are represented as Approval, as described in the "Approval" section of the C011: representing_analysis_result capability. The Approval should be classified. Typical values includes "Reviewed" (urn:plcs:rdl:std:Reviewed) and "Approved" (urn:plcs:rdl:std:Approved).

The instance diagrams in figure 5 and figure 6 illustrates some of some of the general administrative information given in figure 1.

Representation of the detail data section

The representation of the detail data section is based on the usage guidance provided in the "Representing content information" section in the C011: representing_analysis_result capability.

Product breakdown

The detail data section of a fault state analysis result identifies two different breakdown/assembly structures of the product under consideration, namely:

• A Physical breakdown / Assembly structure representing the breakdown elements to which a failure mode applies
• A Functional breakdown / System breakdown representing the affected function/system (failure effect).

Failures

Each record in an fault state analysis result is based on a failure mode being assigned to a Physical_element or a Part, within the Physical breakdown or Assembly structure of the product under consideration.

Failure mode description and characterization

Classification

Each failure mode is represented as a State_definition being assigned to a Physical_element or a Part using Applied_state_definition_assignment. The Part or the Physical_element being assigned with a failure mode, may be referenced in several different ways as described in the referencing_part_or_slot
Error C1: Capability referencing_part_or_slot not in dex_index.xml
, referencing_product_breakdown_element
Error C1: Capability referencing_product_breakdown_element not in dex_index.xml
and the referencing_product_configuration
Error C1: Capability referencing_product_configuration not in dex_index.xml
capabilities.

NOTE    The respective breakdown element/part in the breakdown/assembly is referenced by its identifier. Each identification should be classified. Typical values are [Part_code]
Error RDL1: The class Part_code does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, [LCN_code]
Error RDL1: The class LCN_code does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, [Name_identification]
Error RDL1: The class Name_identification does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

The State_definition should be classified as [FailureMode]
Error RDL1: The class FailureMode does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
and the Applied_state_definition_assignment should be classified as [StateContext]
Error RDL1: The class StateContext does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

Identification

Each State_definition may have a unique identification using the C001: assigning_identifiers capability. The Identification_assignment should be classified as [FailureModeIdentification]
Error RDL1: The class FailureModeIdentification does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

Description

The State_definition. description attribute should contain a textual description of the failure mode.

Cause

The cause of a failure mode occurring should be represented as an Activity being assigned to the Applied_state_definition_assignment representing the association between the failure mode and the product under consideration.

The Activity representing the cause of a failure mode occurring may be classified. Typical values includes:

• "Fatigue" (urn:plcs:rdl:std:Fatigue)
• "Corrosion" (urn:plcs:rdl:std:Corrosion)
• "Abrasion" (urn:plcs:rdl:std:Abrasion)
• "Erosion" (urn:plcs:rdl:std:Erosion)
• "Evaporation" (urn:plcs:rdl:std:Evaporation)
• [LackOfLubrication]
  Error RDL1: The class LackOfLubrication does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• etc

The Applied_activity_assignment should be classified as [CauseEffect]
Error RDL1: The class CauseEffect does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

NOTE    There should be one Applied_state_definition_assignment for each cause of a failure mode.

Predictability

Predictability represented by qualifiers are represented as Classification_assignment of the Applied_state_definition_assignment representing the association between the failure mode state and the product under consideration. Typical values includes [Predictable]
Error RDL1: The class Predictable does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
and [Unpredictable]
Error RDL1: The class Unpredictable does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

Predictability represented as calculated values are represented as an Assigned_property as described in the C076: assigning_product_properties and C079: representing_properties_numerically capabilities. The Assigned_property is assigned to the Applied_state_definition_assignment representing the association between the failure mode state and the product under consideration. The Assigned_property should be classified as [Predictability]
Error RDL1: The class Predictability does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, and the Unit should be classified in accordance with the method used to calculate the predictability. Typical values include [P_F_interval]
Error RDL1: The class P_F_interval does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
and [Weibull_beta_parameter]
Error RDL1: The class Weibull_beta_parameter does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

Detection method

Detection methods are represented as Activity_methods using the referencing_activity
Error C1: Capability referencing_activity not in dex_index.xml
capability.

The association between the State_definition representing the failure mode state and the Activity_method representing the detection method is established via a Applied_state_definition_assignment. The Applied_state_definition_assignment should be classified as [Detection_method]
Error RDL1: The class Detection_method does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, and the Activity_method should be classified to reflect the class of detection method being defined. Typical values includes:

• [Alarm]
  Error RDL1: The class Alarm does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Built_in_test]
  Error RDL1: The class Built_in_test does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Non_destructive_examination]
  Error RDL1: The class Non_destructive_examination does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Vibration_analysis]
  Error RDL1: The class Vibration_analysis does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Particle_analysis]
  Error RDL1: The class Particle_analysis does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Chemical_analysis]
  Error RDL1: The class Chemical_analysis does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Spectrographic_analysis]
  Error RDL1: The class Spectrographic_analysis does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Visual]
  Error RDL1: The class Visual does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Audible]
  Error RDL1: The class Audible does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  
• [Olfactory]
  Error RDL1: The class Olfactory does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .

Context

The identification of the context for which the failure mode is valid, may be defined as one or more of the following:

• Operating state - represented as State_definition as described in the C007: representing_state_type capability. The relationship between the State_definition representing the failure mode and the State_definition representing the operating state is established using State_definition_relationship. The State_definition_relationship should be classified as [Operating_state]
  Error RDL1: The class Operating_state does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , and the State_definition representing the operating state should be classified in accordance with the defined state. Typical values include [Operating]
  Error RDL1: The class Operating does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , [Storage]
  Error RDL1: The class Storage does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , "Standby" (urn:plcs:rdl:std:Standby) and [ColdShutDown]
  Error RDL1: The class ColdShutDown does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .
• Environment - as described in the "Environment" section of the C011: representing_analysis_result capability. The relationship between the State_definition representing the failure mode and the State_definition representing the environment is established using State_definition_relationship. The State_definition_relationship should be classified as representing the operational context should be classified as [OperatingEnvironment]
  Error RDL1: The class OperatingEnvironment does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .
• Mission phase - represented as State_definition as described in the C007: representing_state_type capability. The relationship between the State_definition representing the failure mode and the State_definition representing the mission phase is established using State_definition_relationship. The State_definition_relationship should be classified as [Mission_phase]
  Error RDL1: The class Mission_phase does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , and the State_definition representing the operating state should be classified in accordance with the defined state. Typical values include [Start_up]
  Error RDL1: The class Start_up does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  [Take_off]
  Error RDL1: The class Take_off does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , [Cruise]
  Error RDL1: The class Cruise does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , [Landing]
  Error RDL1: The class Landing does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  and [Shut_down]
  Error RDL1: The class Shut_down does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .

Consequences

Classification

Each consequence is represented as a State_definition. The relationship between the State_definition representing the failure mode (relating) and the State_definition representing the consequence (related) is established using a State_definition_relationship. The State_definition representing the consequence should be classified as [Consequence]
Error RDL1: The class Consequence does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
. The State_definition_relationship should be classified to reflect the type of cause effect relationship. Typical values include "Local_effect" (urn:plcs:rdl:std:Local_effect), "Next_higher_effect" (urn:plcs:rdl:std:Next_higher_effect) and "End_effect" (urn:plcs:rdl:std:End_effect).

Each State_definition_relationship may also be classified to reflect whether the consequence is [Primary]
Error RDL1: The class Primary does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
or [Secondary]
Error RDL1: The class Secondary does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

Each State_definition representing the consequence may also be classified to reflect whether it is "Hidden" (urn:plcs:rdl:std:Hidden) or "Evident" (urn:plcs:rdl:std:Evident).

NOTE    More advanced relationships including conditions can be defined using the C026: representing_condition capability.

Description

The State_definition. description attribute should contain a textual description of the consequence.

Reference to affected functions, systems etc

Each State_definition representing a consequence may being assigned to a Functional_element or a System_element using Applied_state_definition_assignment. The Functional_element / System_element being assigned with a consequence, may be referenced as described in the referencing_product_breakdown_element
Error C1: Capability referencing_product_breakdown_element not in dex_index.xml
capability.

NOTE    The respective breakdown element/part in the breakdown is referenced by its identifier. Each identification should be classified. Typical values are [LCN_code]
Error RDL1: The class LCN_code does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, [Name_identification]
Error RDL1: The class Name_identification does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

The Applied_state_definition_assignment should be classified as [Affected_item]
Error RDL1: The class Affected_item does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

Criticality indicator

Severity

Severity is represented as additional classifications of the State_definition representing the consequence. Typical values include:

• Safety
  • [Death]
    Error RDL1: The class Death does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Serious_injury]
    Error RDL1: The class Serious_injury does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Injury]
    Error RDL1: The class Injury does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Treatment]
    Error RDL1: The class Treatment does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
• Environmental
  • [Contamination_of_land]
    Error RDL1: The class Contamination_of_land does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Ground-water_pollution]
    Error RDL1: The class Ground-water_pollution does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Depletion_of_non-renewable_resources]
    Error RDL1: The class Depletion_of_non-renewable_resources does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Noise_nuisance]
    Error RDL1: The class Noise_nuisance does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
• Operational
  • [Loss_of_platform]
    Error RDL1: The class Loss_of_platform does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Loss_of_mission]
    Error RDL1: The class Loss_of_mission does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Availability_less_than_specified]
    Error RDL1: The class Availability_less_than_specified does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Minimal_risk_to_mission_or_platform]
    Error RDL1: The class Minimal_risk_to_mission_or_platform does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
  • [Non-operational]
    Error RDL1: The class Non-operational does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    
• Economic
  • "Catastrophic" (urn:plcs:rdl:std:Catastrophic)
  • "Critical" (urn:plcs:rdl:std:Critical)
  • "Marginal" (urn:plcs:rdl:std:Marginal)
  • [Negligible]
    Error RDL1: The class Negligible does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
    

Likelihood

The representation of likelihood may be defined as one of the following:

• Probability - as percentage, is represented as an Assigned_property as described in the C076: assigning_product_properties and C079: representing_properties_numerically capabilities. The Assigned_property is assigned to the State_definition representing the consequence. The Assigned_property should be classified as [Likelihood]
  Error RDL1: The class Likelihood does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , and the Unit should be classified as "Percentage" (urn:plcs:rdl:std:Percentage).
• Frequency - is represented as an Assigned_property as described in the C076: assigning_product_properties and C084: representing_property_value_ranges capabilities. The Assigned_property is assigned to the State_definition representing the consequence. The Assigned_property should be classified as [Likelihood]
  Error RDL1: The class Likelihood does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  . The Unit should be classified to reflect the unit of measure. Typical values include [Hours]
  Error RDL1: The class Hours does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , "Landings" (urn:plcs:rdl:std:Landings), [Years]
  Error RDL1: The class Years does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  etc.
• Qualitative - is represented as an Assigned_property as described in the C076: assigning_product_properties and C080: representing_properties_textually capabilities. The Assigned_property is assigned to the State_definition representing the consequence. The Assigned_property should be classified as [Likelihood]
  Error RDL1: The class Likelihood does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  . The String_representation_item. string_value attribute representing the qualifier value should be classified using Attribute_classification as described in the C010: assigning_reference_data capability. Typical values include "Frequent" (urn:plcs:rdl:std:Frequent), [Probable]
  Error RDL1: The class Probable does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  , "Occasional" (urn:plcs:rdl:std:Occasional), "Remote" (urn:plcs:rdl:std:Remote) and [Improbable]
  Error RDL1: The class Improbable does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
  .

Criticality code

Even though the criticality code may be derived from the combination of severity and likelihood, it may still be explicitly exchanged as an Assigned_property. The Assigned_property should be assigned to the State_definition representing the consequence. The Assigned_property should be classified as [Criticality_code]
Error RDL1: The class Criticality_code does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
. The String_representation_item. string_value attribute representing the qualifier value should be classified using Attribute_classification, as described in the C010: assigning_reference_data capability.

Note

A note is represented as a Assigned_property as described in the C076: assigning_product_properties and C080: representing_properties_textually capabilities. The Assigned_property can be assigned to the either the State_definition representing the failure mode or the State_definition representing the consequence. The Assigned_property should be classified as "Note" (urn:plcs:rdl:std:Note).

Definition of fully acceptable, degraded or fault state

The definition of a fully acceptable, degraded and fault state are all represented as Conditions being assigned to the State_definition representing the failure mode.

The Condition_assignment should be classified to reflect the type of condition. Typical values include [Acceptable_state_definition]
Error RDL1: The class Acceptable_state_definition does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
, [Degraded_state_definition]
Error RDL1: The class Degraded_state_definition does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
and [Fault_state_definition]
Error RDL1: The class Fault_state_definition does not exist in RDL at urn urn:plcs:rdl:std. Check the dexlib/data/refdata/rdl_index.xml
.

NOTE    A typical condition could be the value of a temperature property. The temperature property would the be identified as a condition parameter. This requires the usage of the C076: assigning_product_properties, C079: representing_properties_numerically and C084: representing_property_value_ranges capabilities.