Aircraft Phase-In Series: How To Set Up Maintenance Program Data?
Previously we discussed the aircraft setup, part number administration and setup of installed aircraft components. In this aircraft phase in blog, we will discuss the maintenance program setup and initialization of maintenance events in a M&E/MRO system.
The setup of maintenance program before or during an aircraft phase in can be a highly automated process when the right tools are available. Provided that the right data sources are present a standardized digital process can put in place. This saves time and increases data entry reliability and consistency throughout the system.
Preparation tasks
There are a couple of preparation tasks required to properly setup a maintenance program in a M&E/MRO system. This starts with obtaining the following items:
- The maintenance planning document (MPD) as provided by the OEM.
o If this is already setup in the systems, it will be a matter of (digitally) verifying that it was setup correctly and that it is complete and able to accommodate future aircraft inductions aswell. Ideally the MPD is a one-time setup that does not require much or any change at all during an aircraft phase in.
- Operator specific tasks.
o It is common that particular aircraft require additional/specific (operator) maintenance tasks to be performed that are not within the MPD.
- Taskcard accomplishment records and/or next due records.
Opportunity: MPD’s as provided by the OEM are often in the same format. An automated data process can be built around it.
What data sets are required for the maintenance program setup?
During an aircraft phase in, the MPD setup is, or should be a one-time activity. Once it is in place it will be a more repetitive process of maintenance task initialization rather than setting up new tasks in the system. However, in the situation of inducting a completely new fleet, the base setup will need to be completed first. This will require the (static) datasets as described here:
- Maintenance planning document base data, which includes codes and definitions:
Zones
Panels
Areas
MSG
Types - examples:
“GVI” – general visual inspection
“LUB” – lubrication. Etcetera.
Special items – examples:
To indicate the origin of the task: “STC”, “AWL”, “CPCP”
Taskcard definitions provided by OEM
General description
Taskcard type
E.g. is it a single running or an in check performable taskcard.
Worksteps
References
Assignment of the codes
Required resources
Part
Manhours
Qualifications
The above data sets mainly provide information required for the tasks execution and provide information for planning purposes. The following elements are of importance to the initialization of the maintenance events:
- Effectivity/Applicability
It should be defined in such a way that future aircraft inductions require no alteration to it. For example, if the tasks apply to all aircraft that are PRE a certain modification. Then one could simply add all those particular MSNs in the effectivity that are currently in the fleet. However, during a next aircraft phase in you want the system to automatically determine if this is true or false. Thus, instead of manually determining the applicable MSN’s at that time, one could setup a rule in the system that determines its applicability. This of course requires that somewhere else in the system the aircraft status is marked as PRE modification in question. But let’s say that later the modification is implemented, then it will be POST and the effectivity will automatically show the correct applicability status again. If done consistently and on a scale of the entire maintenance program, it will be future proof and guarantee a high data quality standard.
Another simpler example could be to set the task applicable to only B737NG, but then to specify on its sub model, B737NG, -900 model. So again, instead of adding individual MSN’s that are considered of the -900 model one could define the -900 model as a rule on the effectivity so that next time a B737NG -900 is inducted it will automatically show the correct status. And if a B737NG -800 is inducted it will show not applicable.
- Maintenance time requirements
This will either be, days, hours cycles or APU hours/cycles. The most accurate way to manage it is to associate the time requirement with the effectivity/applicability setup. As an example, the -900 model could have a different time requirement than the -800.
Initially it might seem a lot of work to setup the effectivity/applicability and time requirement in such a detailed logical manner, however after multiple aircraft inductions it will save a lot of time and review. Thus, making life easier.
- Operator specific tasks (not included in MPD)
Same setup applies as regular MPD tasks.
- Maintenance check definitions associated with the tasks
The following data sets are considered the dynamic datasets and are required to initialize the maintenance tasks. These consist out of the following:
Taskcard next due information (Date, hours, cycles)
Having above figures in conjunction with up to date aircraft utilization figures will be sufficient to initialize the tasks in order to derive the to go values on the maintenance forecast.
Taskcard last performed/history (Date, hours cycles)
Used for historical purposes and to calculate the next due based on the time requirement that is setup in the maintenance program.
The process step by step
As soon as the static data elements of the MPD are setup we can go ahead and focus on the taskcard last done and next due phase in. We now have a list of last done and next due data outside our M&E/MRO system that we want to get implemented as soon as possible in a reliable way. There are several automated data checks that should be applied. Which in turn will raise questions that require an answer:
1. Is the aircraft eligible and assigned to the target maintenance program?
2. Does the taskcard exist in the system?
If not, should it be created?
3. Is the taskcard controlled by another maintenance requirement?
For example, controlled by a rotable requirement that is managed elsewhere in the system. A link can be established between these events avoiding duplication of event tracking.
4. Is the taskcard applicable?
If not, is this correct or does it require change?
5. Is the taskcard on demand?
Meaning a next due is not required but can be left without limits.
6. Are the dimensions for the due date aligned with the dimensions of the system its time requirement?
7. Has the taskcard previously been performed?
This is relevant to the calculation method for the next due. Ideally the next due should be determined by taking the last done + the interval defined in the system time requirement. This is the preferred method opposed to taking the next due as defined by a previous operator as there may exist differences in requirements.
8. Once initialized is the task due in the future?
If not, is it a data setup issue or has it truly overrun its requirements?
9. Are tasks still left not initialized?
Why is there no data available to initialize the tasks?
Should the tasks be applicable in the system?
A flow chart has been created to visualize this process:
How to avoid common pitfalls
There are some common pitfalls that can be avoided when setting up maintenance program data:
OEM supplied MPD’s are often provided in a clean uniform format. Automate the creation of MPD’s in the system.
Setup the maintenance program in the system in such a way that it eases future aircraft inductions. Essentially think ahead and make it future proof.
Again, ease the phase in process by agreeing on a standardized data format that will be provided by the previous operator. This way a repetitive process can be enabled, which will save a lot of time.
When possible, use the last done values with the system time requirement to generate the next due values for the maintenance requirements. A previous operator could use different time requirements for its operation and therefor any provided next due values might not be the same under the new operator.
Realize that the majority of maintenance program data induction can be automated during an aircraft phase in. Only the exceptions that come out of data migration scripts require human interaction to make certain decisions.
What is next?
In the next blog of aircraft phase in series we will be taking a closer look at the modification control setup and all related topics that need to be considered for a successful aircraft phase in to a new system.
Aircraft phase in series:
✓ Maintenance program
Modifications & Documents
Extras
How EXSYN can help
EXSYN's team of aircraft data and aviation experts utilize a proven framework and methodology that has been applied to millions of terabytes of master data and includes:
EXSYN’s NEXUS solution to reduce project costs and duration
EXSYN’s data warehouse to accelerate your phase-ins
Set up the best strategy for your situation based on years of experience with any aircraft type
Migration of both structured and unstructured data
ISO 27001 data security certified migration approach