Maintenance Programme Optimisation- Aviation
How we can help
We offer strong technical and process support, training and the essential web based on-line software application required to assist in the development of MSG3 based maintenance programmes.
A number of our partners have first hand experience gained with the UK Civil Aviation Authority, in aircraft Type Certification processes including Maintenance Review Boards (MRB), which overseas amongst other things the creation of the maintenance programme.
An Introduction to MSG3
Maintenance Steering Group (MSG) Logic; is a hierarchical, ordered, logic based process to derive a minimal, safe maintenance programme. It was first developed in 1968 for the Boeing 747 aircraft. Since then its development and use have been widespread. Today it is the origin of every maintenance programme for large commercial aircraft. It is accepted and supported by aviation authorities world-wide.
This summary guide discusses the general principles of the standard not its technical use or implementation, which is an extensive subject.
What is MSG3?
It is currently at version three (MSG3) revision 2011.1 and has seen continuous development since the 1960′s. Although it is designed and applied to aircraft, it can be adapted and used in other contexts. We have seen the principles of MSG3 used very successfully in the development of a maintenance programme for railway rolling stock and can envisage many other scenarios where its principles could be put to good use. The formal document: “Airline/Manufacturer Maintenance Program Development Document‐ MSG‐3 2011.1″ is published by Airlines for America (A4A). The document can be purchased from their website, although at the level discussed in this briefing that is not necessary, we would recommend further research of the topic before delving into the standard itself.
MSG3 in Context
MSG3 is a sophisticated, highly developed approach to maintenance programme design. The MSG process is primarily used to develop the systems based programme, an aircraft will also have a Structural Inspection Programme (SIP) to manage fatigue and damage tolerance, and an Environmental Deterioration Programme (EDP) with specific corrosion prevention and ageing systems methods. Together these will make up the full and approved Aircraft Maintenance Programme (AMP) for which, the MSG3 analysis forms the base document.
The MRB and Aircraft Type Certification?
The MSG3 analysis is a way of satisfying, in part, the ‘Instructions for Continued Airworthiness’ which are required for aircraft Type Certification.
An approval process is laid over the MSG3 analysis known as a Maintenance Review Board (MRB). The final output of the MSG3 analysis is a report to the MRB, the Maintenance Review Board Report (MRBR). We won’t discuss the MRB process and format in any detail here, but it is formed and chaired by the regulatory authorities and is fully part of the aircraft Type Certification process itself.
There is an extensive FAA Advisory Circular on this subject (AC 121-22C) which details the process in some detail, it can be downloaded from the Federal Aviation Administration’s website.
An MSG3 analysis is essentially a top down, system by system failure modes analysis, which is then used to derive the minimum maintenance actions required for safe operation. Working Groups are formed to review a system or group of systems. Each Working Group then reports to a Steering Committee, which is responsible for compiling the MRBR.
1. Maintenance Significant Items (MSIs)
The first task is to identify each significant system and component. This creates a list of Maintenance Significant Items (MSIs). Each MSI must be described in some detail, to a predefined format. These will be numerous.
2. Reliability Data
The working group must then provide reliability data for the MSI, again in detail. This can be inferred to some extent by testing and operating data from other types and service experience of other aircraft. Any novel features or technology need special attention.
3. Functional Failure Analysis
After the MSI is identified and defined, the Functional Failure analysis must be performed, where it will list all Functions, Functional Failures, related Failure Effect and Failure Cause(s).
The Failure Effect are listed for each MSI and must state the final consequences of the failure. Failure effects may be hidden or evident. There can only be one effect for a given functional failure. If more than one failure effect has been identified, either the functional failure, or the failure effect is incorrectly defined.
4. The Failure Effect Analysis
The Failure Effect Analysis (known as the Level 1 Analysis) is performed to define the criticality of the Functional Failure, based on its Failure Effect. This analysis consists of a set of 4 questions normally displayed as a logic tree.
The logic flow is designed whereby the user begins the analysis at the top of the diagram, and answers to the “YES” or “NO” questions will dictate direction of the analysis flow.
The end result of this level one analysis will be to have placed each Failure Effect for each MSI in one of the following categories:
- Evident Safety (Category 5).
- Evident Operational (Category 6).
- Evident Economic (Category 7).
- Hidden Safety (Category 8).
- Hidden Non‐Safety (Category 9).
Evident Safety (Category 5).
This must be approached with the understanding that a task is required to assure safe operation. If this is not the case then a re-design is required.
Evident Operational (Category 6).
A task(s) is desirable if it reduces the risk of failure to an acceptable level.
Evident Economic (Category 7).
A task(s) is desirable if the cost of the task is less than the cost of repair.
Hidden Safety (Category 8).
A task(s) is required to assure the availability, necessary to avoid the safety effect of multiple failures. If this is not the case then a re-design is required.
Hidden Non‐Safety (Category 9).
A task(s) may be desirable to assure the availability necessary to avoid the economic effects of multiple failures.
5. Failure Cause Analysis
The next task is to complete the level 2 analysis. This Failure Cause Analysis is handled in a similar manner for each of the five failure effect categories. The purpose is to identify tasks to prevent the failure causes from happening. There are six possible task resultant questions in the failure effect categories as follows:
- Is a lubrication or servicing task applicable and effective?
- Is a check to verify operation applicable and effective?
- Is an inspection or functional check to detect degradation of a function applicable and effective?
- Is a restoration task to reduce failure rate applicable and effective?
- Is a discard task to avoid failures or to reduce the failure rate applicable and effective?
- Is there a task or combination of tasks applicable and effective?
There are lots of criteria around the use of these questions and how they must be answered, but this is enough to give an overview of the basic concept.
6. Task Intervals
The next stage is to determine task intervals and then to combine tasks and remove duplications. Typically zonal inspections will be created at this stage, to combine tasks within a geographic zone, (the cockpit for instance) where tasks are defined for particular inspection levels. This again is quite a complex and highly structured process.
At this stage you have a minimum list of tasks that are applicable and effective to be carried out at specified intervals, combined where practical and effective to do so.
This analysis will form the core of the MRBR. From here each operator (airline) will build their own maintenance programme, based on the MRBR and their own operational profile.
This is the very briefest of overviews, however, you will have gathered this is a very robust, detailed, highly structured process, which will generate a huge amount of data. It is normal practice to use a software application to manage the data requirements for an analysis of this nature.
Airlines will normally add to the MRBR for their own programmes, but again will use some kind of MSG3 based analysis to ensure the tasks added are really applicable and effective. Tasks intervals can be escalated, indeed even removed, but very solid justification will be required, especially in the early life of a type.
For further information, or to discuss how we can help please contact us HERE