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

·  capabilities of the existing support infrastructure.

Definition of an expected usage scenario does not preclude use of the product in a different context. It will however provide the owner with a clear understanding of the basis on which the support solution was develop and provides a basis for reworking the support solution, to reduce costs and improve availability, if the operating context changes.

4.1.2.3  Failure Modes Effects and Criticality Analysis

During the design phase, the Reliability Engineers will seek to eliminate or minimise the potential for the product to fail. There will, however, always be a residual number of failures that it is neither technically possible nor cost effective to eliminate. Each one of these remaining predictable failures should be supported by a maintenance strategy to reduce the risk of failure to acceptable levels and to provide a remedy should failures occur.  As the failure may occur well into the life of the product, there is benefit in retaining a record of the failure analysis, and the reasoning behind the related support solution.

4.1.2.4  Task Analysis

The maintenance strategy adopted is likely to comprise a series of condition monitoring, scheduled, occasional and exceptional tasks. Each of these must be analysed to determine requirements for support infrastructure, special tools, piece parts and necessary maintainer skills. All decisions reached should be recorded, with a reasoned justification, for subsequent reference.

4.1.2.5  Task Description

Each task identified in the task analysis will be supported with detailed descriptions of how the task is to be undertaken. Task descriptions may include technical drawings, illustrations and video clips in addition to formatted text. Some text may be identified as safety warnings or procedural cautions[4].

4.1.2.6  Task Association

The tasks identified during the task analysis may be generic to the failure mode. To create a viable maintenance solution the maintenance task must be associated with the components of the product to which they apply.  For example the failure mode “fails to inject fuel due to injector blockage” may lead to a task “clean the injector”.  This task can then be associated with each of the injectors fitted to the product, as uniquely identified within the product configuration record.

4.1.2.7  Spares Analysis[5]

The acquisition and storage of spare parts is a major cost driver. The Support Engineer will therefore strive to keep stockholdings of spares to a minimum by matching recommended holdings to the predicted take off derived from the maintenance strategy adopted. Various algorithms exist to assist with this process. The conclusions are very sensitive to changes in input parameters such as component Mean Time Between Failure estimation, logistic pipeline delay time or component remanufacture lead time. The analysis results will have to be revisited whenever algorithm parameter values are updated or the given usage pattern of the product is changed.

4.1.3  Support Engineering In-Service

4.1.3.1  Failure and Discrepancy Reporting

Support Engineering during development will require much engineering judgement, including the interpretation of data from similar products for which operational experience is available.   To optimise support performance, and minimise in service costs, data should be collected to check whether the support system is working as intended, or as currently required.  Defining the required feedback is part of Support Engineering. Feedback can be grouped under two headings:

4.1.3.2  Failure Reporting and Corrective Action System FRACAS

Failure reporting generates the in-service statistical data necessary to confirm the analysis that produced the support solution and to provide the owner with cost-of-ownership information required for effective asset management.  Failure reports should be associated with the relevant predicted failure, and with the failed item, to provide context for further analysis. The level of failure reporting will vary.  The process typically operates at two levels of intensity: