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

To manage products over their life cycle it is necessary to address these different views of product and to distinguish between the product ‘As Required’, ‘As Designed’, ‘As Built’ and ‘As Maintained'.

This can be accomplished as follows:

Ø  the life-cycle of a product starts with the definition of a product_concept which is the idea of a product as defined by customer needs. The ‘AS REQUIRED’ view of a product is defined by the mission need that created the demand for the product and is described by its required functionality (product_requirement: e.g. expected features, capabilities, performance, et cetera);

Ø  the design activity, based on the required functionality, progressively defines the physically realisable objects or the ‘AS DESIGNED’ view of the product. The set of related designs is then used to manufacture a quantity, possibly thousands, of physical products (product_instance);

Ø  the exact configuration of each of these product_instance(s) in terms of parts/components identification (e.g. by serial number and/or lot number) defines the ‘AS BUILT’ view of the product.

Ø  later in the life-cycle each product_instance is maintained, repaired and part/components are replaced due to malfunctions or configuration changes. All information related to these activities identify the ‘AS MAINTAINED’ view of the product.

In its broadest sense, a product consists of the sum of its product_concept + product_requirement + product_design + product_instance.

These objects are closely inter-related as shown in figure 1. Relationships should be maintained throughout the life cycle.

Figure 1 – The product architecture

The product_concept object is the collector or common root for all subsequent objects. The product concept is the idea of a product as defined by customer needs. It identifies a deliverable product as perceived by the customer ( e.g. an item in the catalog of a supplier).

A product_concept may exist without a product_design or a product_instance. It is related to the object product_requirement which describes the required performance or behaviors of the deliverable product. The object product_requirement, in turn, is related to product_design making it possible to relate functionality to design.

The product_design object is the container of (1) functional design, (2) physical design and (3) support design. It is related to product_concept and to product_instance. The latter is the relationship between a specific actual object (identified, for example, by its serial number) to the design information from which it was developed. This relationship is optional since it is not always possible or necessary to relate product_instance(s) to a product_design.[9]

The product_instance object is the container of data related to the ACTUAL physically existing object (e.g. an actual helicopter with a tail number).

5.2  The PLCS Perspective

The PLCS objective is “  … to improve product availability by improving the quality and availability of the technical information needed to support a complex product in-service”. The term product in this definition should be seen and understood as the product_instance described above (only a physically existing object may be supported).

For PLCS perspective the main focus will be placed on the product_instance object.

To support a product_instance in-service, we need to know its ACTUAL configuration, role, condition state, maintenance history and operational history (AS BUILT, AS MAINTAINED). Then we need a mechanism to link the product_instance to (1) the maintenance directive resulting from the support engineering activity; and (2) to the technical data resulting from the functional and physical design activity. In this proposed architecture the linking mechanism between product_instance and the other product objects is achieved through relationships.