What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

Electronic Aircraft Maintenance Log Book?

S. Soule

Active Member
I have been making entries into a conventional paper logbook since my first flight in N227RV in the fall of 2001. I'm thinking of transitioning the records to an electronic logbook, this being the 21st Century and all. Any recommendations? SJS
 
You can try out planelogix if you're willing to pay for the subscription, otherwise I think you will have to roll your own, I use Google drive as a simple digital backup for the logs
 
There are a number of commercially-available options, but a spreadsheet will be the most durable long-term. Set up your own columns for tracking items, organize it the way you want to, etc. etc.

LibreOffice will give you a free and 99.99999% Excel compatible spreadsheet. Google Sheets will give you something you can edit anywhere you have an internet connection.
 
Consider a database

Warning, this is an eye roller:

We tend to go for flat data entry like we are used to on paper.

But if you are going to organize electronically then consider organizing your data the way you actually work, not the other way around.

Any Maintenace activity is an event, and those events are related to a lot of other things. If you have the gumption to create a relational database (it's not much different than a flat entry system), you'll actually get a lot more bang out of it with less typing. In fact for the same amount of data it is much smaller.

Just a thought
 
What is an easy to use relational database these days?
Honestly, the easiest is Google Sheets. Tables on separate tabs, or in separate Google Sheets that are all linked and referenced using each document's Google ID.

Relational Databases are just a collection of flat databases (ie. spreadsheets).
 
If you use an electronic log book, how do you handle entries that require a signature- like your annual CI and entries that need to be done for your Transponder test (and IFR certification if required)?
 
If you use an electronic log book, how do you handle entries that require a signature- like your annual CI and entries that need to be done for your Transponder test (and IFR certification if required)?

From AC 120-78A, 2.1:
(5) The electronic form of signature must be attached to or associated with the electronic record being signed.
(6) The signature must be permanent and the information to which it is attached must be unalterable without a new signature.
(7) There must be a means to preserve the integrity of the signed record.
(8) A valid electronic signature must prevent the signatory from denying that he or she affixed a signature to a specific record, document, or body of data (non-repudiation).


The easiest way is to create an Adobe Acrobat form with a digital signature block to meet this requirement. Each competed and signed form would be a record that meets 5-8 above. You can export data from Adobe forms to a spreadsheet or database if you are wanting to track or associate data from multiple records. You could cover all the record types with a single form by using a list box for airframe, engine, prop, avionics, etc.

John Salak
RV-12 N896HS
 
Relational Databases are just a collection of flat databases (ie. spreadsheets).

That's mostly true. A few rules need to be actively enforced to keep things straight when relating disparate spreadsheets. Most of those rules are automatically enforced in a database application.

It's when we have one to many relationships that spreadsheets hold us down with their one line to one event format.

For example: for a Condition Inspection we may have a hundred tasks, sometimes more sometimes less. Many of those tasks may share a single vendor such as AC Spruce. Many of those tasks involve disparate data such as battery shelf life. Documenting like we work in a spreadsheet would be a nightmare without a lot of assumptions (covered in our logbooks by a signature). But a database manages the one to many, or many to one, or the occasional one to one like we do when we go about or daily lives. I am not saying you have to write down everything you do! But wouldn't it be nice if the entry we make to document our condition inspections (an event) did so by automatically confirming all the assumptions such as the available life of all our life limited parts without our actively going through all those other pieces of paper or disparate spreadsheets?
 
Last edited:
One important consideration to keep in mind is that, some day, your plane will likely be sold. Will the new owner be able to use your electronic logbook or reasonably be able to convert it to another form that they can use (paper?)? I've used Filemaker Pro for ages (although I haven't built a new database in it for several years). It can output in Excel format but likely not in very usable format. Paper output would depend on how the database was originally built. I don't have the answer here. Just be sure to consider this before you pick your poison. The wrong format may make your wonderfully useful log absolutely useless to a buyer.
 
Also, the software changes over time and sometimes lose compatibility with older data sets across these changes. For this reason I'll be sticking with paper for my main logs, and backing them up electronically by scanning the log to a PDF.

Dave
 
Electronic data stability over time

Database construction isn't for everyone, it takes some thought and time. I am only encouraging those that really want to do the best they can with electronic record keeping to think hard about the dead ends of flat sheet recording. Spreadsheets are great for rapid number crunching as in accounting. Their popularity and familiar look lent to their use in data recording so much so that the real tools for storing data fell out of most people's scan. Then when our spreadsheets become unwieldy people often abandon them. Unfortunately migrating spreadsheets into a database later on can be an unrealistic effort. The data will import, but the structure is often unusable.

Losing data from a database because of new software I would have to think is pretty rare if we start with anything remotely current. Even when you use a database application that combines the data (tables) with the 'front face' (data entry forms, reports, queries, etc) such as ACCESS .accdb , there is a way to export the raw data into standard .dbf formats that any database application can import. You can also dump tables into spreadsheets and import those if you like. Or get really basic and export your data into some ASCI text document. In comparison I think you are much more secure keeping your data in a database format over time, compared with spreadsheet formats. Database formats have been around a LONG time.

Reverting back to paper is simply a matter of printing a report of your desired maintenance activities. That product can be paper or .pdf Probably not a bad idea to do just for housekeeping.

For those still reading: Any database can build you whatever spreadsheet output you want. This is not true the other way around. Unless you build your spreadsheets like database tables, but why would we do that?
 
What got me thinking about it was that I create a word processing document for each maintenance or inspection activity and write out what I did while I'm doing it. Then I print it and glue it into the aircraft log. I do sign the work off in the log. I just got to thinking that the word document was the record I look up, using the computer, when I want to look back at the record of work - for example, to see when I replaced those brake pads. The little logbook just sits in the locked file cabinet. Steve
 
What got me thinking about it was that I create a word processing document for each maintenance or inspection activity and write out what I did while I'm doing it. Then I print it and glue it into the aircraft log. I do sign the work off in the log. I just got to thinking that the word document was the record I look up, using the computer, when I want to look back at the record of work - for example, to see when I replaced those brake pads. The little logbook just sits in the locked file cabinet. Steve

You are a great candidate for databasing! I first built a database almost the same way. In the 90s I needed a 'smart' word processing document so that subordinate departments could not make mistakes on important reports. At the beginning, the data was actually incidental to the rules imbedded in the application at the data entry phase. Over time, lookback needs into the data began to grow in popularity and then automation of certain tasks became obvious.

Right now you are working for your data, since you are already doing electronic entry why not get that data to work for you?

For example you can set up your application to email you once a week with a report stating upcoming maintenance requirements, life limit replacements and admin requirements (like updating EPIRB registration) in the next 30, 60, and 90 days. Or here is another task: Advanced Flight uses a comma deliminated data format entry method to display maintenance logs in the cockpit. You can update those logs through a cockpit interface but you can't edit them there. Writing a fresh set of maintenance records from your database onto a memory card is just a mouse click.
 
Last edited:
Canada/US differences

I've done a fair amount of digging into the aircraft logbook requirements for Canada and the central document here is the journey log. This is expected to contain an entry for each flight or series of flights in a single day which shows the date and air time of that (or those) flight(s). In most cases we are required to carry this document on the aircraft. It also records any abnormal occurrence along with maintenance entries. For amateur built aircraft it can contain the full maintenance record for that aircraft.

My question is in regards to aircraft log requirements in the US. Is there a similar document that records daily flight activity, or is it just a maintenance log?

Full disclosure here, I have done some work in developing an electronic journey log for use in Canada that meets the requirements set out for electronic records. I see in this thread that the US electronic record requirements have a lot of similarities. This question is meant to explore whether I could develop something that could be used in either country. I'm not selling or offering anything, just researching whether there would be potential to develop this for more than just my own use from a technical standpoint, not a marketing one.
 
My question is in regards to aircraft log requirements in the US. Is there a similar document that records daily flight activity, or is it just a maintenance log?

I'll weigh in for you. I believe the most direct answer to your question for basic Part 91 Operators is: No.

But for an active maintenance database we do indeed need a way of tracking hours even if it isn't required of us.
 
For those still reading: Any database can build you whatever spreadsheet output you want. This is not true the other way around. Unless you build your spreadsheets like database tables, but why would we do that?
Well, mostly because 90% of us aren't software developers who want to hack around to create a database interface or learn to write sql queries.

If you're just going to create a spreadsheet at the end of the day from your databases, then there's no reason to use the database if you're already familiar and handy with spreadsheets.

There's nothing magical about database tables... They're just spreadsheets with specific columns. Any set of spreadsheets can be turned into a database if desired, but given the added complexity for the average user, i'm not sure why one would want to.
 
Databases enforce data integrity

There's nothing magical about database tables... They're just spreadsheets with specific columns. Any set of spreadsheets can be turned into a database if desired

That's just not true. Database tables are integrity driven. Spreadsheets generally don't concern themselves with the integrity of the data. Spreadsheets that have calculated values in their cells will have a lot of difficulty migrating into a data table. But more importantly, a properly conceived relational database is 'normalized' in a way that we just don't do in spreadsheets. The extra effort in relational table organization just doesn't happen in a spreadsheet that is treated like a log entry. So even if we can migrate our spreadsheet somewhere down the road, the organization won't support proper data relationships.

So why go through the effort of normalizing your data? The big benefit is flexibility. A properly organized and normalized database can answer any question supported by the data. That's the magic of a database, if you build it right it will serve data needs that haven't yet been realized. The dead end we get into with spreadsheets is that somewhere down the road we will need to ask the data a new question that the flat information format just can't answer.

I would say that at least 90% of us were not aircraft fabricators/assemblers when we started out in this community, and that wasn't a reason not to learn and do. Certainly the extra work required to develop a database is not for everyone. But when considering electronic logging it is a mistake to assume a database and a spreadsheet are the same thing.
 
Last edited:
That's just not true. Database tables are integrity driven. Spreadsheets generally don't concern themselves with the integrity of the data.
The integrity of the data is controlled by whatever tests you create in the database that validate the data at time of entry. That's equally possible in a spreadsheet... Cells can offer you drop-down lists of options, for example, or you can apply a formula to validate the entry in each cell.

Again, for the average computer user, none of this matters, but the ability is there if you want to learn how to use it, and it's a much shorter learning curve to add some basic entry-checking to a spreadsheet than it is to take on the learning necessary to create a full relational database... just to manage the maintenance on *one* aircraft.

And for what it's worth, on a daily basis I use both large relational databases and large sets of interlinked spreadsheets that could be relational databases but aren't because it works better for us to use them this way.
 
I never thought about creating my own relational database. I have a MacBook, not a Windows PC. That means Access is out as an "easy" solution, not that anything to do with Access is easy. I wondered if there was a solution off the shelf.

So, if I had a maintenance entry:

"March 7, 2022. Removed main wheels, L and R, replaced brake pads L and R with new Matco ###-### pads, inspected attachment hardware and measured rotor thickness. Tested brakes and taxi to bed brake pads. Returned to service. <<name>>, <<Repairman #>>"

I might have "brake" and "rotor" in the home-built database, so I could run a report someday on just the brake work over the past 20+ years? Ditto "wheel," "tire," and "tube." The database could generate a reminder to replace the batteries in the ELT every three years.
 
The Planelogix solution looks very good, and even though it's another subscription, I'm guessing it would increase the value to a future buyer. I'd of course recommend keeping a paper copy of everything somewhere.

As someone that dabbles in software development, I'd say writing an app/DB to keep your logs in is pretty ambitious, but then again, so is building an aircraft.
 
Back
Top