PLCS Statement of Technical Requirements. Technical Requirements Product Life Cycle Support. Configuration Management, страница 20

25.  product_physical_design properties may be represented using STEP IR constructs[16];

26.  in addition, product_physical_design properties may be represented by plain text, structured text (SGML, HTML, XML), drawings, video, audio or references to external documents;

27.  product_physical_design may be classified. Class of product_physical_design may in turn be organized in a class hierarchy;

28.  a class of product_physical_design may have a set of predefined properties that must or may be filled-in to represent a product_physical_design instance that is a component of that class;

29.  product_physical_design changes should be addressed by change process information such as change request, implementation directive and applied solution.

5.5.3  Product Support Design

In simple terms, the objective of support engineering is to determine what can go wrong with a product and what has to be done to sustain availability ( see 5.1.1 ). This includes actions to repair or to prevent problems from occurring.

Basically, support engineering consists of Failure Analysis, Task Analysis, and Spares Analysis. These activities are conducted on the basis of the user’s Support Requirements. (Note: support requirements, a sub-type of product_requirement, relates to the association between product_concept and usage_scenario).

The focus in this section is NOT on how these Analysis are conducted, but on the information that are generated by these activities (output) which constitute the logistic technical information needed to support a product_instance during its life cycle.

5.5.3.1  Failure Analysis

It is assumed that, at the end of the design phase, a residual number of predictable failures still exist. This occurs because it is either impossible or not cost effective to eliminate the failures or because they result from external agents. Each one of these predictable failures should be addressed by a maintenance strategy to:

·  reduce the risk of failures to a minimum (preventive maintenance);

·  provide a remedy should the failure occur (corrective maintenance).

A failure involves a product_physical_design while performing a certain function in a particular usage scenario.

More precisely, the predicted failure of a product applies to one or many product_physica_design and happens in the context of one or many product_functional_design and of one or many usage_scenario. (see figure 8)

Figure 8 – failure[17] context

A failure is described by its:

·  Cause: failure causes may be classified as internally generated within the system by an inherent property of the product or produced by external factors (usually human or environment);

·  Effect: failure effects fall into two major classes: local_effects (e.g. increased engine smoke) or failure_inducing_effects (e.g. failure in an oil pump leading to a failure of the engine).

The notion of failure_inducing_effects introduces the need to manage a cause-effect chain. At a very simple level, two failures, Failure 1 and Failure 2, may be associated to define that Failure 2 is caused by Failure 1.

In a more complex situation, figure 9, a particular failure (Failure 4) will occur only if two other failures (Failure 1 and Failure 2) occurs together or if a third (Failure 3) occurs by its own and not with the first two.

In a cause-effect chain it should be possible to combine failure causes with:

·  AND operators, when the related causes must occur together;

· 

OR operators, when the related causes can but need not occur together;

·  XOR operators, when the related causes are mutually exclusive.

Figure 9 – consequential failures

The association between failure and effects may be used to capture additional information such as probability and safety hazard severity (e.g. critical, minor, none ).