Hello Esayas,

This is achievable with a specific workflow that involves removing a component in a backdated work package and inducing a erroneous timeline of removals and installs. Let’s say a component was installed on an aircraft at time t-2. On date t-3 one cycle was accrued against the aircraft. On date t-1 two cycles were accrued. The component has 2 cycles of usage, since it only participated in flights for date t-1.

What can happen from this point is for a backdated removal of the component to occur at date t-4. The real time is t+0, a work package is started with a date in the past of t-4, we find the usage for the aircraft and assemblies at date t-4. Any removed or installed component will have its usage adjusted by Assembly Current Usage - Work Package Assembly Usage. In the example above, the delta is 3 cycles. If you remove the component in this way, we will apply a usage adjustment of 3 cycles to the removed component, and it will end up with -1 cycles of usage.

In the case of complex TRK components, the entire tree of the component will receive this usage adjustment, so as the composition of this component is altered, the usage adjustment is only occurring on the existing tree. If different components were introduced in the time between t-4 and t, those components will receive the same adjustments.

In addition to this, if flight adapter v1 is used to accrue usage and the aircraft hierarchy has changed between when the flight was completed and the actual arrival date of the flight, that version of the product is not able to reconstruct the composition of the aircraft at a time in the past. In this case we apply usage to the existing tree. This could later lead to negative usage under the right circumstances.

Another scenario is when a work package is in work and usage is accrued during the period between the start and end of a work package. The component removals before and after this usage accrual will take the same adjustment,  because the work package usage is the anchor for this operation.

What we’ve delivered to improve this area

In 8.3-SP6 we have a new UI for editing task history. This UI allows for technical records to make specific adjustments to the installation dates of inventory. If this new installation date crosses the threshold of a usage accrual, the appropriate usage adjustment is made.

Also in 8.3-SP6 we performed an enhancement request when installing or removing assemblies. Since usage is accrued directly on assemblies, leveraging out of sequence gives us the capability to adjust usage history, tasks, and deadlines. When backdating an engine swap we have maintained usage history, with the new engine appearing on any affected usage accruals, and all associated components, tasks, and deadlines are adjusted.

What is in the pipeline to further improve this area

In the next service pack, 8.3-SP9, we are working on further refining the work package usage adjustment feature. The usage adjustment that occurs will begin to use the task completion date, instead of the work package usage. This feature will be useful for operations that perform shakedown testing before closing a work package, and also for engine shops who may bench test the thrust of an engine prior to closing a work package. The feature will also add an event to the historical record that will give traceability to the end users of these usage adjustments, and the task and/or work package that caused the usage adjustment. Please note, the work for this feature is not yet completed, and may be altered at any time solely at the discretion of IFS.

Thank you, Robert Bellemare, I would appreciate to go through all the root causes that require more illustrations with timeline chart or other reading document to understand the behind logic and most frequent one in order to controlled manually if possible while doing part installation and removal, work package handling until 8.3-SP6 or 9 patches realized.

Hello Esayas,

We can gladly organize further discussions on this topic, including live demos of the scenarios I have discussed. Reviewing your data, with inventory affected by this problem, will help to identify causes of these deviations. In a light review of your account history I see there was a review of the Rolls Royce DAC usage algorithms in Q1 2023. In Q3 2019 we had a small discussion about differences in the presentation of TSI and TSO values in the product following an upgrade. This topic has not recently been raised within the support process, that I could easily identify.

We host a bi-weekly support call with your organization that can be used as the initial touch point for these discussions. Please reach out to Girum for details on when these calls take place.