Tuesday, May 28, 2019

What constitutes a "valid" flight entry?

With any data system, one must be prepared to do validation on the data that goes in.  A logbook is no exception to that rule.

It turns out, though, that there are surprisingly few validation checks that can be universally applied to a flight - there are a lot of things that look like an error in some scenarios, but which are perfectly valid in others.

An example that I am asked about frequently is that the system does not flag flights where Dual plus PIC plus SIC does not equal Total time.  For much of flying in much of the world, that equation is satisfied, but (in particular) it is not here in the US, where you can simultaneously log Dual and PIC if you're appropriately rated for the aircraft yet receiving instruction.

Probably the most common scenario where a flight frustrates data validation is "catch-up" flights, where you make one or more entries in your logbook to represent totals from prior (typically paper) logbooks.  Such flights typically include large numbers (larger than any single flight could actually have), and a mix of things that might be difficult or impossible to do in a typical actual wheels-up-to-wheels-down scenario.

Over the years, it seems that whenever I put in a validation check, I soon find counter examples of perfectly acceptable flight entries that violate my rule.

So in an evolutionary process of "survival of the fittest", here are the checks that have withstood the test of time:

  • Valid aircraft - every flight must be associated with an aircraft (even if no actual flying was done; you can generally use any aircraft you like for ground sessions - since the times are zero, any aircraft will work).  This is because the aircraft's model determines all sorts of attributes about the flight, such as the category/class, whether it was complex or high performance or turbine, etc.
  • No negative numbers.  I've yet to find a scenario where negative numbers are allowed.
  • Hobbs start after hobbs end.  (I don't currently validate tach time because I don't currently perform any computations on tach time).
  • Flight start after flight end or engine start after engine end (I don’t currently validate block time) 
  • Full-stop night landings + full stop day landings greater than the total landings (unless total landings is 0, in which case I auto-fill it)
  • Full-stop Night landings indicated without any night flight.
  • Night takeoffs at towered airports + night takeoffs at non-towered airport (which, kinda by definition, is all of the possible night takeoffs) is greater than total night takeoffs
  • More described approaches (e.g., a property indicating two ILS approaches) than logged approaches
  • Comments or Route field too long (13K and 128 characters, respectively)
  • Date before 1900 or more than 2 days from "right now" in Pacific time

No comments:

Post a Comment