Using RT for fleet management?

Many, many years ago I used RT in the usual way - tracking tasks in an IT company, but now, I want to use it to manage a fleet of aircraft.
These aircraft have tasks that are scheduled on dates, and also on hours flown, and a few other misc counters etc, and the hours are interesting, because they’re not exactly the same. Ie: you have total aircraft hours, and you have hours on a particular gauge, and they won’t necessarily match (gauges get replaced and can’t be reset to match airframe hours).

I had a quick poke around, but wasn’t sure. Can RT track tasks on arbitrary counters for starters as well as dates, and can it do any maths to calculate a value based on another value?
So for example, I have a plane, and it has 4500 hours of total time, but the odometer reads 1450. At 1540 hours (odo) it will be due for some maintenance, and at 250 days it will be due some other maintenance.
Possible to do with RT?

You can have custom fields associated with tickets (and queues) and they can include more or less any value including dates. I assume for the “hours flown” you’ll need to be entering all this information somehow every time the aeroplane lands/comes for maintenance? (Sorry I don’t know much about maintaining aircraft! :wink: ). RT has custom fields that can store either dates or numbers (or text!) and it also has scrips that you can write yourself using pretty much the full power Perl, including the ability to update these custom fields (as well as normal RT fields). Maybe you can leverage those?

So throwing out some random ideas: what about two queues per aircraft. One has tickets logging aircraft hours, etc, whilst the second has actual maintenance tickets for that aircraft.

The first queue could then have a range of custom fields attached to the queue for the various hours/days periods/thresholds different things take, and maybe some custom fields for “elapsed counters”. I’m assuming that different planes may have different requirements, so that list will be different for each queue associated with each plane. Then on every maintenance visit you create a new ticket in this queue that has a custom field for the hours flown (either since the last visit or cumulative depending on which is easier).

You then create a Perl scrip on the first queue that runs On Create that compares the hours flown data in the new ticket with the values in the queue’s custom fields, maybe updating some of the “elapsed” CF values and also comparing the current date with the last ticket date in that queue to check if you’ve reached any of the scheduled date-based maintenance windows. This scrip can then create more new tickets in the second queue, one ticket per thing that needs attending to.

On the second queue, when a ticket is resolved you can have other scrips that run at the On Resolved condition that reset some of the elapsed time counters attached to the first queue.

This way you have two queues: one has tickets in that logs maintenance arrives and hours flown (and possibly things like pilot comments, fluids levels, quick visual inspection notes that a wing is missing, etc) and a second queue that has all the actual maintenance tasks tracked with a ticket each.

You’ll need to “link” the pair of queues together in some way so that the scrips running in one queue know which other queue to update/create tickets in. You can link the pair of queues together in several ways - for example they may be named in a standard way based on the aircraft registration number with two different suffixes (say, " maintenance arrival" and " maintenance tasks"). A scrip can easily find the name of the queue the ticket it is attached to is in, so then can quickly strip off the suffix and attach the other suffix to find the other queue. You could probably do similar standardised name with custom field naming for the things you need to check on each aircraft. That way the scrips you write may be able to be generalised across different aircraft queue pairs, rather than having to write different ones for each pair of queues you have per aircraft.

You could of course extend this out further - you might have other queues for customer billing, parts ordering, etc that scrips in these queues could create new tickets in depending on what needs doing to an aircraft. But that is, as all good maths books say, “an exercise for the reader”. :slight_smile:

1 Like

The two tickets is a good idea - the way it works is we have a 100 hour/365 day “interval”, during which time certain other tasks have to be done, some are reactive (propeller fell off, please re-attach!) and others are scheduled, either on hours flown or calendar time, or both.

Thank you for the suggestion!