Has any Mx client implemented the proposed Clock stoppage solution yet?

Yes.  We have one customer who has validated this in their TEST environment, migrated the solution into PROD and applied it against several aircraft. 
 

We’ve also delivered this solution to two other commercial airlines for consideration of using it in their environments. 

Does this require any particular version of Maintenix to be installed prior?

Who would be able to connect with our Business Team to discuss in more detail, is that our account rep? We have an All Operator Message from Bombardier, but I’m not sure I want to make the call myslef on if/how we can utilize this solution.

This solution is specific to users of IFS Maintenix .  Contact me via email (nelson.quirk@ifs.com) with the specifics of the customer environment, etc and I can get you aligned with the right business team to see how we may be able to help.

Hi Harvey,

The solution is applicable to any customer running 8.1-SP2 or above.

Hi,

We have reviewed AOM700-1162 and the software will be delivered compatible with Bombardier’s advice on the matter.

Hi all,

The product now supports a rollback function for single aircraft. By removing all blackouts from an aircraft your task deadlines for this aircraft will return to their initial state, having a sched to plan matching the baseline, and a deviation matching the original extension on the task. The documentation in Nelson’s post has been updated to revision 1.1.

So, as I understand it, Clock Stoppage is an extension of the Blackout option, adding calendar based limits to the solution. To use Clock Stoppage one must also be using Blackout and therefore the additional functionality of Blackout would also be put in effect.

Hi Harvey,

That is correct. The blackout feature will push estimated due dates to the right for usage-based deadlines. The period of blackout will replace the forecast model, replacing estimated daily usage increase. The two effects are complimentary, and will give a better visibility to planners on the expected maintenance once the storage period is lifted. 

Could you give me an idea of what the planning process would be like when preparing for a return to service of the aircraft if the blackout/clock stoppage function has been used? 

Hi Harvey,

Without this solution in place

• Overdue calendar tasks will collect on aircraft, and must be completed to return the aircraft to service.
• If you have sched to plan high values your forecast tasks will be rescheduled from LASTDUE, earlier than you are entitled.
• The short term horizon of the aircraft’s usage based deadlines will shift every day. For example, a task with an estimated due date in approximately 7 days will be updated daily to be due in 7 days.

With the solution in place, you can estimate fleet maintenance demand as you reactivate the fleet.

• You will perform less work to return your aircraft to a serviceable state. Calendar tasks will be credited with extensions, and will not come due during the storage period. At a high level, if a task had 10 days remaining when it went into storage, it will be due 10 days after the aircraft is returned to service.
• Your program will be permanently credited. Calendar task chains will benefit from an extension to the maintenance program, and the first rescheduling will be from WPEND/LASTEND.
• Your fleet maintenance can be planned now. Usage and calendar estimated due dates will be fixed to your estimated return to service date. You will have a better visual of the maintenance schedule of an aircraft.
• Less overdue tasks on the aircraft will reduce the amount of tasks that need to be reviewed during storage, and highlight life limits, and other activities that will be required for return to service.

Hi Robert,

I haven’t seen this in play yet but I’m reading both the documents from Airbus and Boeing. As I understand it the clock stoppage can be applied to the entire maintenance program (Excluding Mandatory Tasks CMR ALI etc) ie not just those going to be overdue.

Just to get an understanding

-if my blackout period is set at 01-Mar-20 thru to 01-Sep-20 (6months)

Does this mean Maintenix  would apply a deviation of 6month on every selected task (not in our exclusion list) 

ie those that are coming due

1. C1 check was due 20-Apr, it would apply the extension to 20-Oct.

2. 7 day check was due 10-Mar it would be due 10-Sep?

What about those that aren’t due?

3. C4 block that’s due 20-Apr-21, would it also push these tasks forward the 6 Month Blackout, ie  20-Oct-21.

How would the system then respond to a baseline revisions for tasks/blocks where instances were affected by the blackout? Ie a change of calander schedule, 18 months down to say 12?

 Would the blackout period continually be re-evaluated against such instances where tasks that have a start value that was prior/during the blackout period?

Thanks, looking forward to test it out.

Hi Bobby,

These topics are also covered in the document attached to Nelson’s original post, see the “Effects On Tasks - Extension rules”, and “Effects On Tasks - Task Revisions”. I am updating the document as the software continues to evolve based on feedback. Latest revision is 1.2 from 27-Apr-20.

For Boeing aircraft, the quick answer is yes, the whole program with specified exclusions is eligible for up to 6 months of extension from its original due date. All your examples are correct for Boeing aircraft. 

For Airbus the rules are more complicated. Extension limitations are based on the rescheduling interval, and tasks whose due date is during the storage period have their extensions capped based on Return To Service (RTS) date, rather than original due date. Some of Airbus’ rules related to limits from RTS are not mathematically possible to reach depending on your interpretation of the rules, but the limits have been specified, and the software adheres to them.

1. The due date is 20-Oct-20. C1 check is permitted a 6 month extension from RTS because the rescheduling interval is > 1 year, and it came due during storage. The maximum creditable extension is 6 months.
2. The due date is 01-Sep-20. Tasks under 30 days interval must be completed for RTS, our 7 day check will be extended up to RTS.
3. The due date is 20-Jul-21. C4 is limited to a 3 month deadline extension from original due date, because the rescheduling interval is <= 1 year.

The system operates with some known constraints. Task revisions that change your calendar deadline will maintain any existing extension, but the sched to plan value will revert back to baseline. Task revisions that do not modify your calendar deadline will not cause any change. We could customize the product to check the Enable Manual Scheduling option on individual tasks to prevent baseline synchronization from altering the deadlines, but we evaluated the risk to customers as too high to have this as the default behavior.

For blackout evaluation, we store the total blackout duration, and return to service date for each aircraft. Any change to either of these values will trigger a re-evaluation of all deadline extensions.

To those who are curious about my statement about limits not being mathematically possible, here is an example. For an Airbus task C1 with a 3 year interval that is due 20-Apr-20. Given an aircraft in storage from 01-Apr-20 to 01-Apr-21. According to the rules, this task is permitted an extension up to 6 months from RTS, or 20-Oct-21.

Our interpretation is that the extension in days can be up to a maximum of the total storage period, 365 days on our example. Therefore this task is eligible for an extension of 365 days, and due 20-Apr-21.

Another interpretation of the rules is that you get credited up to RTS, then have the capped extension applied afterwards. The total storage time was 365 days, but you are only allows to be credited 180 days of extension after RTS. The eligible extension is 346 days from original due date to RTS + 180 days limited extension. The total extension is 526 days, and due 20-Oct-21.

We have elected to implement the first interpretation, which is the safer option. In this interpretation it is impossible for the task to be due any further than 19 days after returned to service.

If your organization has discussed this topic with Airbus, and they present an alternate interpretation, we would like to review the information.

New features are available now. Please inquire through the support portal if you are interested in these latest developments. 

1. Giving the control to your engineering team: The software was originally designed to use one query with baseline data rules to identify tasks. It worked best if the list of tasks stayed consistent. Using the task definition tags feature, we are giving your engineering team full control over which tasks are identified for extensions. Inclusion tags for standard extension rules. Exclusion tags to roll back changes for task definitions that were incorrectly included in the program. Exception 1 and Exception 2 tags for Airbus specific rules. A data loading tool will soon become available to bulk load tags into the system.
2. Support for tasks going in and out of the storage program: Using tags means the list of tasks that are included in the program will change over time. The software now supports bringing new tasks in, and taking tasks out. Tasks removed will recover their original deadline information, including custom extensions, and sched to plan information.
3. Airbus non-variable extensions: The software now applies a 90 or 180 day extension to tasks, relative to the return to service date. Formerly the software extended deadlines using the period of the time the aircraft spent in storage. Return to service dates are limited to AMPES’ 180 days from the beginning of storage. This overrules the discussions from earlier in this thread.
4. Support for multiple release to service dates / storage periods: Deadlines extensions, and the maximum allowable extension, are calculated based on the release date nearest to the task’s original deadline.
5. New change detection: The system will monitor the storage period, all return to service dates, and recent tag changes to determine if changes should be rolled out to aircraft.