feature: aircraft maintenance section

[jereanon]

I've recently been preparing for my first condition inspection on my aircraft and feel like there is potentially space in MyFlightbook to add a few different things:

1. Airframe / Engine logbooks
2. AD Compliance
3. Tracking components on your aircraft (e.g., make/model/serial) and their relation to AD compliance.

I spent a significant amount of time going through my (new to me) airplane's log books to make sure I am AD compliant. I'd love to start automating some of this, e.g., Giving all relevant ADs for a make/model (Lycoming / O-360), and marking them as irrelevant/complied/etc.

I use MyFlightbook to track my flights and just discovered it's open source after starting to build the above.

I'm just interested in starting a conversation about these features and if this is desirable.

Thanks, Jeremy

[KayRJay]

Recently, Eric and I have had a similar conversation about adding MX and AD tracking capabilities. I too would like to see MFB track aircraft upgrades and purchases of "flying products" (equipment, costs, suppliers, date purchased/installed, serial numbers, etc.). There is a great deal of important info about a plane than just dates of required inspections and compliance with ADs. MFB could track dates, locations, airports, service centers, technician names, hobbs readings, squawks, and costs of various maintenance/inspection actions., etc. Anything that you might put in an aircraft log book could/should be entered into MFB, just as you can log flights in the same (but better) way you use a manual/printed flight log book (or spreadsheet).

It would be very useful if MFB could track this type of info. There is value-add in a number of areas:

• Makes available a pre-defined, well thought out and free service (rather than user-built, incomplete and unique systems)
• Backup/recovery
• Data validation ... structured data can be value-checked ...almost always better than free form
• Reporting and querying (easier to query and more powerful than with a spreadsheet)
• Sharing information with partners, club members
• Correlating equipment with flights and dates (these are poor examples, no doubt) was item X (e.g., FIKI, oxygen) was present or used on a given flight? oil used (quarts added) between oil changes number of flights (not just hours) since last annual service number of landings on a set of tires ability to tie rentals to costs (if I could designate that my plane was rented for a given flight)

An alternative tool I’ve found is PilotPartner (https://www.pilotpartner.net/aircraft-maintenance-tracker/), which has a free MX capability along with a flight log (which is covered by a subscription fee). I've not thoroughly analyzed PilotPartner. Crewlounge:Club may someday offer similar facilities. Of course, I'ld like to use one tool.

Eric has argued that he doesn't feel MFB can particularly add value here, vs. other alternatives or a user-defined spreadsheet. I happen to disagree, as MFB does more than store and display data. It can validate it on entry, summarize it, analyze it, provide notifications (e.g., of upcoming deadlines), make it easily sharable (e.g., for members of a club or renters of an aircraft), and more.

On the other hand, I don't/can't do the work! No doubt it would be a lot of work to add these features to MFB.

[ericberman]

To be clear, I didn't say MFB can't add value, I said I couldn't necessarily add value. I've had a lot of requests around this over the years. I'm a pilot and I know the regs around being a pilot and I have to log my flying, so I understand the customer problem there reasonably well, and I have an itch to scratch, and enough time to write code to scratch it. I don't own/maintain an aircraft, though, so I don't know the nuances of what is needed in that space nor am I scratching my own itches there, and I don't have much extra bandwidth to dive into a bunch of new functionality.

I think aircraft logbook functionality is incredibly useful/valuable, it's not a trivial amount of work to do in a way that is acceptable to authorities, handles all the scenarios properly, etc. If someone wants to dive in, I'd be more than happy to provide guidance/integration/advice. I just can't drive it.

[ericberman]

I thought I'd write down some of the issues to think about in designing an aircraft/airframe logbook feature (which is absolutely distinct from a way to track arbitrary maintenance items on an aircraft)

• Access to logbooks. Aircraft on MyFlightbook are shared, while logbooks are inherently private. Can anybody with that aircraft in their account view the aircraft's logbook? Can anybody edit? Or should the aircraft logbook be separate from but linked to an aircraft? How would multiple owners share it (or a CFI give access to a student for their checkride)?
• Relationship between logbook and aircraft. Some aircraft are cloned into two versions - e.g., on floats in the summer and wheels in the winter; need to think about how these two can share a logbook. What happens if two aircraft are consolidated/merged?
• Security - AC-120-78A compliance. Most of what's in your personal flying logbook does not need to be signed; most of what goes into an airframe logbook does. All flying logbook entries that are signed are signed by a second person (e.g., your CFI). But a mechanic typically self-signs, which means we need to re-think through how we ensure compliance for electronic record keeping. (See here for how MyFlightbook ensures compliance today)
• Your flying logbook is always yours - it never belongs to someone else. But aircraft get sold/transferred. Need to think about that scenario.
• The mechanic who needs to do entries into a logbook and sign them often does not fly. They would need an account with access to the aircraft logbook, subject to the two issues above.
• While MyFlightbook already has support for tracking deadlines for AD compliance (i.e., when is the next one due?), need a way to track AD's along with a history of the various actions that they required
• Assume that for paper you'd have to have a way to upload scans of paper, same as you can do for endorsements?
• Need a way to print - the layouts will necessarily be different than a flying logbook.
• Most importantly, I think it's super important to ask "what problem are you solving". At a high level, there are two: (a) electronic recordkeeping for the airframe logbook, and (b) ensuring that required work/inspections are performed. You can already do the latter without an airframe logbook using custom deadlines (and I'm sure there are enhancements that could make this easier/smoother). I've frankly never had a really good answer for the former, though. For all of its ancient flaws, I'm not clear what would be so much better about doing an airframe logbook electronically over paper (whereas I could go on for days about why electronic is better than paper for tracking your flying). The more clear you can be about what is deficient about paper for an airframe logbook, IMO, the more obvious the optimal solutions become.

[KayRJay]

Thanks for taking the time for writing down your thoughts on this, Eric. It is helpful to move the process along, even if you yourself won't be implementing this proposed new feature. As you know, I'm a newbie, though I have owned a Cirrus SR22T for about a year. I am currently paying my CFI to oversee management of my plane, but I'd like to have an electronic way to do so myself (in addition). So, take these comments with several large grains of salt.

Of course the aircraft logbook is of primary interest to the owner(s) of the aircraft. MFB should track ownership, including multiple owners for a given aircraft, as well as changes in ownership (dates, prices, partial ownership fractions, etc.). I'm not certain, but it doesn't seem a CFI or mechanic should have write access to the log.

All of the issues you raise are good ones. Again, I'm probably not the best person to answer these questions given my limited experience in aircraft ownership. Here goes anyway ...

Access to logbooks: owners could choose to share the aircraft log with other named users (for read only access). There is probably not a good reason to make an aircraft logbook public.

Relationship between logbook and aircraft: I don't know enough to understand the scenario of two versions of the same aircraft. On first blush, it would seem that adding floats or wheels would simply be recorded as a "change in equipment". There are reasons to correlate flights with changes in aircraft status/equipment, etc. based on the date of a flight and date of an equipment change, for example. This might overlap with "properties" (flights with floats vs. wheels, for example), but some correlation might be best explored otherwise.

Security - AC-120-78A compliance: To me, the written aircraft log book (kept in the aircraft) would be the official one, and would need to be signed, with copies of work orders pasted in, etc. The aircraft log in MFB would be a secondary logbook. So, I wouldn't expect to use MFB for compliance, and signatures would not be necessary, especially in an initial release.

AD tracking: While it might be helpful to upload a scan of the AD itself, this could be done as a PDF attachment. (Thanks for adding that feature recently!). In an ideal world, MFB could automatically upload ADs and manufacturer service bulletins specific to each aircraft and serial number. Not a required feature by any means. However, it would be helpful to have MFB record a summary of the ADs and service bulletins that have been issued and addressed (including date, location/service center, cost, etc.)

Printing: only a simple format would be needed, no customization, etc. Even just supporting export to .CSV and letting the user do his own reports would be sufficient.

Electronic vs. paper log: Record-keeping in general is the point, rather than compliance or currency, etc. It's obvious that it's much easier to do many things with an electronic format vs. a paper format.

• Sharing of a single physical book is hard

• A physical book can become lost, damaged, or illegible

• An electronic log can record things not required for compliance, avoiding unnecessary clutter: -- optional equipment purchases, dates, prices, Hobbs meter, etc. -- squawks from inspections -- non-inspection equipment upgrades and repairs (e.g., tire change)

• Costs of ownership in general

• Easy queries/lookup by criteria other than chronological order (e.g., when did I replace that tire?)

So in short, the answer to "what problem are you solving?” is that it's the same problem that having a written aircraft log solves. It keeps all the info you need to be sure your aircraft is safe and compliant with ADs, but also adds the value of recording other non-compliance, non-safety issues and expenses. So, it’s not only fixing the “deficiencies” of a paper aircraft log, but adding more utility.

[ericberman]

Possible simpler solution: allow people to enter an A&P into their profile and digitally sign modifications to the maintenance.

Still completely "open source" in that anybody can then add entries to the logbook. Gotta think through if it even meets AC120-78A, but perhaps as a handy reference?

Need to be able to paste in all sorts of additional ADs/scans (separate from aircraft pictures, presumably), and ensure that required ADs are tracked (deadlines?) in a way that can't be deleted accidentalliy.