At any time during its life cycle, the product - a material or intellectual entity or software - may encounter unforeseen events, thus generating the uncontrolled risk (established or potential) of non-conformance to the specified requirements and expected behaviour.
Any departure from an expected situation constitutes an anomaly.
The potential consequences of an anomaly on the product must be assessed, controlled and possibly corrected if need be, through suitable actions to guarantee the specified performance throughout its entire life cycle.
As is the case for any product changes, anomalies and their processing are an integral part of the product's history. As such, it is necessary to be aware of them and manage them in order to understand at any given moment, the actual status of the product (applied configuration management), and to ensure effective monitoring.
In view of this, any anomaly, regardless of its nature and apparent importance, must be recorded and processed in accordance with previously defined methodology.
This methodology, referred to as anomaly management, guarantees the traceability of unforeseen events and non-conformances and ensures that their consequences have been properly dealt with.
It also contributes to the lessons learned process at both project level and on a more global quality scale (subsidiaries, generic products, enterprise, etc.).
This document is based on the CNES Standards Reference (RNC) document "RNC-ECSS-Q-ST-10-09 Non-conformance control system".
Anomaly management is under global responsibility of those in charge of product development and flight readiness. It must be implemented from the outset of manufacture/integration of product elementary components and sub-components up to the end of in-orbit commissioning.
The methodology is established by drawing up the product assurance specification and the associated requirements, in a preliminary manner in phase A, more detailed in phase B, so as to be completely operational before phase C kicks off.
The product assurance plan describes the provisions in place for organising and guaranteeing anomaly management.
The anomaly processing procedure is broadly organised into the following stages:
- The reporting phase, including the immediate actions, recording and classification of the anomaly and informing those concerned (laboratories, manufacturers, CNES, etc.) ;
- The assessment phase, consisting in identifying the causes of the anomaly, and assessing the effects and proposing corrective actions;
- The action phase, including the identification of actions, the execution and checking of the actions deemed necessary;
- The closure and data archiving phase.
The Project Manager is responsible for setting up the anomaly management system. Depending on the structure of the project team, he/she may delegate all or part of the action to the Product Assurance Manager, ultimately approving the final closure and processing statuses.
1.1 Immediate actions
As soon as an anomaly is detected, there are three types of action to be carried out:
- conserve, as far as possible, the circumstances and conditions in which the anomaly appeared (temperature, electrical configuration, configuration of connections and of use, etc.) since they are often essential to the cause identification analysis ;
- take measures to prevent immediate consequences that the anomaly encountered may cause (avoid knock-on effects and the propagation of failures) ;
- state the anomaly on the internal document used for the operation underway (a manufacturing log, inspection report, log book, etc.).
The Product Assurance (PA) manager and/or the Project Manager check that there is in fact an actual anomaly. If it is confirmed, the anomaly is recorded on a Non-conformance Report (NCR) (see PAF-14).
In the interests of efficiency, this report is written by the person who came across the anomaly, with the help and supervision of the Integration Quality Assurance supervisor
It provides all the information required for understanding and processing the anomaly.
In particular, the report contains a clear and complete description of the anomaly, including the environmental conditions and affected parameters. This description must be explicit enough to be understood by all of those concerned.
When the anomaly has been identified, the Integration Quality Assurance supervisor, the PA Manager and/or the Project Manager must assess the severity of its consequences.
Depending on its severity, as defined in the PA specification for the project, the anomaly is classified as major or minor.
Major anomalies are those which affect at least the following areas:
- safety of people or equipment,
- operational and functional requirements (reliability, lifetime, availability, etc.),
- interfaces with hardware and/or software under someone else's responsibility,
- qualification or acceptance tests,
- EEE components.
Other anomalies are classified as minor; they may be consulted by the next level up, at which point the anomaly can be reclassified.
1.4 Informing parties concerned
After recording and classifying the anomaly, all NCRs for "major" anomalies are circulated as soon as possible to the people concerned by its assessment and processing.
When the reporting has been completed, an analysis is performed by the Project Manager and/or the PA manager in conjunction with the parties concerned. The analysis aims to:
- identify the causes of the anomaly ;
- assess the actual and potential consequences: deterioration of the product's technical and operational functions, schedule modifications, effects on costs.
This assessment can be carried out, for the most critical cases, by setting up a Non conformance Review Board (NRB), for ad-hoc consultation of experts and to involve the customer more effectively in the process of moving forward and resolving the issue.
This assessment results in substantiated proposals for action (NRB work sessions, minutes, test report, technical memo, etc.).
These actions and the observations/statuses which may arise are varying in nature:
- use as-is (with or without a deviation) ;
- product modification leading to the re-examination of the qualification status and the modification of the Definition File (DF) in compliance with the configuration management plan ;
- repair: restoration in accordance with the manufacturing procedures ;
- scrapping the product affected.
The results of the analysis, the proposed actions, plus the elements from the results which influenced the final status obtained, will be featured in a file to be appended to the non conformance report or referenced in it.
The report will be closed when all the parties responsible for the project agree to accept the final status, the actual implementation of the re-validated corrective actions and the completeness of the NCR processing file.
3.1 Deciding upon actions
The assessment makes it possible to identify the decisions to take and the actions to carry out.<^>In general, decisions in a project are taken during special sessions for processing and reviewing anomalies, by a board made up of the Project Manager, the PA Manager and the technical experts involved.
This Non conformances Readiness Review Board will be carried over to the next level up in the case of major anomalies.
The decision-making level changes depending on the classification of the anomaly:
- for a minor anomaly, the decision lies with the Project Manager of the product affected;
- for a major anomaly, the decisions depend on approval from the project's "customer" representative. The representative's formal approval must feature in the non conformance report.
3.2 Execution / checking actions
The actions decided upon are carried out by the relevant technical managers. The PA manager makes sure that the actions are actually carried out.
3.3 Monitoring anomalies
The PA manager ensures that anomalies are monitored and makes sure that the anomaly management process is globally controlled. An anomaly summary table with the following headings can be used for monitoring:
- NCR No.
- DATE ANOMALY REPORTED
- NCR MANAGER
- ANOMALY DESCRIPTION
- CORRECTIVE ACTIONS
- ACTION OWNER
- CLOSING DATE
When the actions have all been executed and checked, the product has been repaired and newly validated or judged fit for flight as-is, then the anomaly must be formally closed. Closure is confirmed when the non conformance report is signed by the Project Manager and the next level up, in the case of a major anomaly.
In the interests of traceability and in order to contribute to lessons learned, the data from the non conformance report are archived, preferably in electronic format.
|Risks||Underestimation of seriousness of problems |
No analysis of impacts at higher level
|Recommandations||INVESTIGATE AND PROCESS ANOMALIES |
Management of Anomalies