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

The third and bottom level is the product id name (e.g. part number, serial number, file name). It is provided by the Organization and is assumed to be unique within the context of that Organization.

4.2.3.3  Identification of Physical Products

4.2.3.3.1  Conceptual State Identifiers

Part Number: It is an identifier consisting of an alphanumeric string assigned by the design agency for an item and used to correlate the product design with the physical instances of the product.

4.2.3.3.2  Realised State Identifiers

Part and assembly unit / batch identification. Each physical part or physical assembly must be identified by marking it with the part number (design identification). If it is critical to safety, performance, or operation, each individual part or assembly must also be identified by a unique product tracking identifier (serial number and/or lot number). In some cases, more than one type of product tracking identifier may be assigned (e.g. serial number and lot number); in this case, the correlation between product tracking identifiers should be maintained.

·  Serial Number: It is an identifier consisting of alphanumeric characters which is assigned sequentially in the order of manufacture or final test and which uniquely identifies a single item within a group of products manufactured from the same design.

·  Lot number: It is an identifier consisting of either a date or a string of alphanumeric characters which uniquely identify a group of units of the same product which are manufactured or assembled by one producer under uniform conditions and which are expected to function in a uniform manner.

User-Defined Identifier: The user may need to issue additional identifier to End Item (e.g. tail number, plate number) in order to manage them within the user management system. In addition, it may be necessary to issue additional user-defined identifiers to parts and assemblies. This is done when there is the need, for example, to manage spare parts and stocks within the existing user management system. If a user-defined identifier is assigned, the correlation with identifiers defined for different life cycles should be maintained.

4.2.4  Configuration Change

4.3  Maintenance

4.3.1  Purpose of this Section

This section identifies the business and information requirements to be addressed by Maintenance Management.

4.3.2  Background

The objective of a Maintenance Management system (MMS) is to deliver the required product availability by implementing the support solution derived through the Support Engineering activity.

Maintenance tasks can be classified according to type. The terms ‘servicing’, ‘preventive’ or ‘corrective maintenance’ provide one such classification. Current maintenance concepts have added new terms such as ‘condition monitoring’, ‘scheduled’, ‘occasional’ and ‘exceptional’. This document uses the latter terminology with the assumption that ‘preventive’ can be mapped to ‘scheduled’ and ‘corrective’ can be mapped to ‘exceptional’. 

4.3.3  Implementing a Maintenance Management System

4.3.3.1  Data Take-on

The first task, when commissioning a maintenance management system, is to establish the information baseline for the selected support solution that is relevant to the product instances on which maintenance will be performed.   As the support solution may evolve over time, periodic updates of the maintenance management system may be needed to implement revisions. This PLCS development must support a managed evolution from current systems to ensure that no information is lost about maintenance or usage history, or product condition.

4.3.3.2  Configuration Reconciliation