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

·  Normal Reporting.  Where failure occurrence and recovery action conform to predictions, reporting may be limited to a report that a failure has occurred.

·  Intensive Reporting.   Where more detail is required, either because insufficient data was available during development to predict in-service behaviour with confidence, or because the failure rate, spares usage or maintenance costs are higher than expected, a period of special reporting may be justified.  This may include the reporting of additional information related to failure occurrences (e.g. the hours run prior to failure), more details of the failure itself or the tracking of replaced components through a repair loop to correlate information from strip reports with failure instances.  Intensive reporting may also be required early in the equipment life to confirm performance against contract requirements.  The nature of the feedback required will be specified on a case by case basis.

4.1.3.3  Discrepancy Reporting and Corrective Action System DRACAS.

Although the Support Engineer will have made every effort to predict and provide solutions to all the potential failure modes of the product, provision must be made for when this process itself has failed. Three levels of discrepancy are recognised:

·  Analysis Errors. In-service experience will identify where the planned procedure for managing an anticipated failure mode has failed to provide an accurate or complete solution.  Response to reported errors may vary from a minor adjustment, such as changing the planned duration of a task, to a major reworking of the response to the particular failure.

·  Additional Failures.   A discrepancy may report additional failure modes, not identified during development, but revealed by in-service experience.  These will need to be analysed and maintenance strategies generated or amended accordingly.

·  Stores Usage[6]. Inventory management procedures should detect when spares usage does not match expectations. Such a discrepancy will bring into question the validity of the original Support Engineering analysis and may require a reassessment of the product design, the maintenance approach, of spares holdings or supply policy.

4.2  Configuration Management (CM)

4.2.1  CM Basics

In simple terms, Configuration Management (CM) is the process of defining and controlling the identification of a product, its structure and related items so that all parties who work on the product can know:

·  what has been designed

·  what has been built

·  what has been, or should be, changed

·  what related items are applicable to the product

Accurate, timely information concerning the configuration of a product and its related items is needed throughout the life cycle to achieve cost-effective manufacture, continued safe operation and efficient in-service support.  However, the level of effort applied to Configuration Management will vary with business circumstance.  In some applications it may prove necessary to control the configuration of each instance of the product to a high level of accuracy to ensure safe operations (e.g. flight safety, nuclear plant).  In other circumstance, where errors can be more readily accepted, control configuration may have a more limited scope.

PLCS must provide capability to define and manage the configuration of complex items, over their full life cycle, to the serial number level. The level to which configuration management is applied to any specific product will remain a business decision.

The functions of CM include Configuration Identification (CI), Configuration Change Control (CC), Configuration Status Accounting (CSA) and Configuration Audit (CA).

4.2.2  Concept and Definitions

4.2.2.1  Configuration Identification (CI)