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

54.  a product_instance may have a serial number that enables to distinguish it from other product_instance(s) based on the same design;

55.  a product_instance may have a lot or batch number that enables identification of a group of units of the same design which are manufactured or assembled by one producer under uniform conditions and which are expected to function in the same manner. A block identifier may be assigned to designate a quantity of consecutive production of product_instance(s) which will have similar characteristics;

56.  a product_instance may have both a serial number and a lot number. At least one of the two is necessary to identify the product_instance. If both are assigned, a correlation of serial numbers and lot numbers is to be maintained;

57.  the capability to assign additional customer defined identifiers should be provided. If multiple identifiers are assigned, their correlation is to be maintained;

58.  a product_instance may be categorized in  classes of product instance. A class of product_instance(s) may in turn be organized in a class hierarchy;

59.  possible classes should be defined. Class of product_instance may include role, function and condition state (e.g. “in repair”[28], “spare parts”).

60.  a product_instance structure may be the assembly of other product_instance(s). As a minimum, a product instance structure should include the component product_instance identification.

61.  a product_instance structure may be subject to changes due to a configuration variant or replacement of defective items. The old components (predecessors) and the new components (successors) shall be identified. The capability to associate a date, time and organization responsible for the change with each change implementation and to maintain history and rationale of changes shall be provided;

62.  product_instance structure changes due to configuration variant shall be referenced by Configuration Change entities such as change_request, implementation directive and  applied_solution;

63.  a product_instance may be controlled by zero, one or many organizations at a given point in time;

64.  control of a product_instance may have different forms (e.g. operational, logistics, storage, etc. ). There is exactly one controlling organization associated with each control form at a given point in time;

65.  product_instance control may change over time during life-cycle. The capability to associate a date and time with each transfer of control and to maintain history of control shall be provided;

66.  a product_instance exists at one location at a given point in time[29]. It may be moved from one location to another. The capability to associate a date and time with each change of location and to maintain history of location change shall be provided;

67.  a product_istance is characterized by the properties defined for the related product_design;

68.  in addition a product_instance is characterized by zero, one or more actual characteristics that are either measured from or assigned to the object. Qualifiers (e.g. calculated, measured ) may be applicable to characteristics.

69.  product_instance characteristics may be organized in classes. A class of product instance characteristics may, in turn, be part of a class hierarchy;

70.  product_instance characteristics may be subtyped according to their representation. Possible subtypes are:

·  narrative: described by a textual description;

·  quantified: defined by a measure and a unit of measure;

·  point in time: defined by a date and time;

·  period : defined by a time measure.[30]

71.  the capability to maintain product_instance(s) maintenance history and operational history shall be provided: