Aircraft Phase-in series: How to setup component data?
In the previous blogs of the aircraft phase in series we discussed the initial aircraft setup in an M&E/MRO system and the setup and configuration of the part numbers. This third blog will focus on the setup of the installed components in the aircraft, the aircraft configuration and maintenance events related to the components.
Components for an aircraft phase in can be categorized in two groups, on condition components and hard time components. The latter requires more data sets such as life values and maintenance requirement associations, additional attention is required to ensure the quality of this data is correct. A standardized data process can be created for an aircraft component induction, this saves time and minimizes errors.
Preparation tasks
Both the aircraft setup process and parts setup must be completed. The component data should be collected for the first assessment. For a typical aircraft component induction, data is received per category:
General hard time components
APU (if applicable)
Engine life limited parts
Landing gear life limited parts
On condition components
Tip: When taking on aircraft from a certain operator it would be wise to agree a standardized format for these data extracts so that it will ease any aircraft phase-in in the future!
Once the data is deemed sufficient and complete a standardized phase in process can start.
First thing to check is whether the component is already present in the system. In some cases it will be found on another aircraft or on a store location. These issues are to be reviewed sorted out first.
If the component does not exist in the system yet, all the standard checks will be done to verify the data completeness and correctness. Again if issues are found they can be corrected either through automated defined script rules or manual assessment.
Once okay, all the component data can be transferred to the system.
The follow up step is to determine whether the component is hard time or soft time. This will determine whether maintenance requirements will have to be created if they do not exist in the system yet.
Once the maintenance requirements are present, the maintenance events can be initialized according to the provided component source data.
What data sets are required for component creation?
Let’s now discuss the minimum required data sets related to the setup component data and why it is required to have them. Aircraft components often come with a lot of data associated to it. This is not very surprising as the components are essentially the building blocks of an aircraft. We listed the most important data sets as follows:
Part number/Serial number
Aircraft registration it is installed in
Owner of the component
The aircraft counters/life values
The aircraft counters are the dynamic data sets of the component, meaning they are changing values. The aircraft counters are:
TSN (Time since new at installation)
CSN (Cycles since new at installation)
TAH (Total aircraft hours at installation)
TAC (Total aircraft cycles at installation)
Installation date
Having above figures in conjunction with up to date aircraft utilization figures, any current CSN/TSN figure can be derived from the system in order to determine when the component is due for a maintenance requirement.
In some cases the values are unknown. This is ok as long there are no maintenance requirements associated with it that depend on these values.
Manufacture date
The MFG date of the component is also required for certain components as maintenance requirements require the value for due calculation. Otherwise it is nice to have data.
Position code
A position code on the aircraft associated with the component. This has previously been mentioned in the parts setup blog. First define a standardized definition table of position codes of the aircraft type and then link them to the components. Ensure that the positions are cleansed or mapped prior to phase in otherwise you will be introducing new, possibly faulty or duplicate positions to your system!
Condition code
A condition code associated with the component to indicate its latest condition status. E.g. “OH” (Overhauled), “SV” (Serviced). The same phase in methodology applies as for the position codes.
Hierarchy/Assembly structure
The component hierarchy has to be present in order to construct the assembly structure in the system (if applicable). So for each component it should be known whether it has a higher component and which part number/serial number that is. This should typically always be present for the engines and landing gears.
Component maintenance requirement related data:
Part requirement type/Maintenance requirement
Is there for example an overhaul, discard/life limited, cleaning or other maintenance requirement associated with the part?
The maintenance time requirement.
Depending on what dimension (Days, hours, cycles) the requirement runs, the life value for that dimension should be known for the component in order to verify and calculate its next due.
Applicability/Effectivity
This could differ in certain circumstance. Examples are the aircraft type the component is installed in, what thrust rating the engine is flown at, aircraft weight etc.
Next due & Last done data
Required in order to calculate or set the next due of the maintenance requirement correctly.
Other data to consider
Other less critical data sets which are also considered part of the component setup are as follows:
Special component counters (Storage days/APU cycles/hours)
Component warranties when delivered with the aircraft
Component measurements
Component history/historical transactions of installation and removals or for example order related order history.
Reference trees
o These are the assembly tree structures as they are expected upon receiving the actual component trees. This can be useful to compare and verify the correctness of the received assemblies and to check for missing parts in the assembly.
Above mentioned items are mostly items which can also be setup at a later stage and are non-critical to the initial aircraft setup/phase in.
How to avoid common pitfalls
There are a some common pitfalls that can be avoided when setting up new aircraft components:
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.
Align the maintenance requirements with the definitions in your system. It is common that the same maintenance requirement is defined differently by a previous operator but essentially is the same that is already setup in your system. Ensure the creation of potential duplicate requirement definitions is avoided.
When possible use the last done values with the 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.
Before a component phase in it is convenient to have the reference assembly tree structure available. This way it can be ensured that the supplied assemblies are correct and as expected.
What is next?
In the next blog of aircraft phase-in series we will be taking a closer look at the maintenance program setup and all related topics that need to be considered for a successful aircraft phase-in to a new system.
Aircraft phase-in series:
✓ Installed components
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