Skip to main content
Question

Managing APU Ratio Changes in Calculated Usage Parameters Without Retroactive Recalculation ("Since Birth")

  • May 29, 2026
  • 1 reply
  • 18 views
J
Do Gooder (Customer)
Forum|alt.badge.img+2
  • Jun
  • Do Gooder (Customer)

Hi Community,

We are currently refining our APU life tracking and maintenance deadline control (Requirement Management) process in IFS Maintenix (CAMO).

To ensure strict deadline compliance and avoid over-running our limits, we maintain system values on the conservative/safe side (Calculated Value >= Actual Value). To achieve this, we model our APU life tracking by applying a coefficient (APU Ratio) to the incoming flight cycles/hours via a Calculated
Usage Parameter.

Our Current Data Flow & Dilemma:

  1. We have an "APU RDG" parameter that stores the raw, actual usage values uploaded automatically from ACARS data in real time.
  2. We have an "APU Cycle" parameter that utilizes a Calculated Parameter (similar to the CFM56 thrust rating constants) to multiply incoming flight data by the defined APU Ratio constant.
  3. Our Production Planning department periodically reviews "APU RDG" and manually adjusts the "APU Cycle" parameter via "Usage Corrections" to align the records.

The Challenge:
APU operational coefficients are adjusted over time based on changing flight conditions (e.g., shifts between domestic/short-haul and international/long-haul operations, where APU utilization frequencies change drastically).

However, in our experience, when a coefficient constant is updated in the front-end interface, Maintenix triggers an automatic retroactive recalculation for that parameter all the way back to the asset's creation date ("since birth"). This completely alters our historical records, which we need to remain locked for data integrity.

Our Questions to the Community:

  1. Has anyone successfully established a cutover process to update a coefficient constant so that it only applies to future incoming flight data without modifying historical snapshots?
  2. We heard that some operators resolve this dilemma by combining multiple calculated parameters (e.g., utilizing a "live data" parameter, a "snapshot" parameter, and a third parameter for combined logic). Could anyone share a high-level configuration mapping or technical blueprint of how this multi - parameter workaround is set up in Maintenix?

Any technical insights, best practices, or custom logic examples (such as utilizing custom PL/SQL DB functions to freeze past intervals) would be highly appreciated.

Thank you in advance for your support!

 

 

    1 reply

    J
    Do Gooder (Customer)
    Forum|alt.badge.img+2
    • Jun
    • Author
    • Do Gooder (Customer)
    • June 7, 2026

    Hi Community,

    I wanted to update my own post because we have successfully resolved this dilemma!

    We managed to figure out a very elegant, multi-parameter configuration that completely prevents the "Since Birth" retroactive recalculation when changing an operational coefficient. Since this workaround utilizes 100% standard front-end features and might help other operators facing the same challenge, I would like to share the technical blueprint here.

    💡 The Solution Concept: Incremental Delta Tracking

    Instead of using a simple, direct multiplication formula, the key is to introduce snapshot constant parameters (_READ) to freeze historical data at the exact cutover window. This isolates future calculations so they only apply to upcoming incremental data.

    The Base Formula: Total_Calculated_Usage = ((Current_Input_Usage - Last_Input_Usage_READ) * Current_Ratio) + Last_Calculated_Usage_READ

    🛠️ Parameter Configuration in Maintenix

    To implement this, we configured the following row items inside the Calculated Usage Parameter screen:

    • Total_Calculated_Usage (Calculated Parameter): The final determined tracking value driving requirements and deadlines.

    • Current_Input_Usage (Input Parameter): The live, cumulative source usage (TSN) synced to the asset.

    • Current_Ratio (Constant): The current multiplication factor.

    • Last_Input_Usage_READ (Constant): Stores the snapshot of the input usage at the exact time of the ratio change.

    • Last_Calculated_Usage_READ (Constant): Stores the snapshot of the total calculated usage at the exact time of the ratio change.

    ⚙️ System Behavior (Blocking the "Since Birth" Recalculation)

    1. Initial Setup (Brand New Asset): Initially, both _READ constants are set to 0. The formula behaves as a straightforward multiplication (Current_Input_Usage * Current_Ratio).

    2. At the Time of the Ratio Change (Cutover Window): When we need to update the coefficient (e.g., the asset has reached 500 input units and 1,100 calculated units, and we want to change the ratio from 2.2 to 1.5), we freeze the historical baseline by saving the current values into the constants:

      • Last_Input_Usage_READ = 500

      • Last_Calculated_Usage_READ = 1,100

      • Current_Ratio = 1.5 (Updated to the new ratio)

    3. The Moment of Cutover: At this exact moment, the formula evaluates as: ((500 - 500) * 1.5) + 1,100. The current delta drops to zero, and the total strictly outputs the frozen 1,100. Because the historical 1,100 is now securely stored in a constant row, Maintenix cannot retroactively alter the past records.

    4. Future Tracking: When the next usage update comes in (e.g., input goes up to 501), the formula isolates only the new increment: ((501 - 500) * 1.5) + 1,100 = 1.5 + 1,100 = 1,101.5. The new ratio applies ONLY to future incremental data going forward.

    🎯 Key Benefits

    • No Back-end Customization (No CRIM): This is achieved purely through standard configuration by utilizing multiple Constant rows in the Calculation Input layout.

    • Component Swap Robustness: Since all input parameters and constants are bound to the component's own serial number (TSN tracking), this logic remains perfectly intact and error-free even when the asset is uninstalled and moved to a different slot or aircraft.

    I hope this blueprint helps anyone else trying to lock down historical data integrity during ratio cutovers in Maintenix!

    Best regards,

    Jun

    Terms & ConditionsAccessibility statement