Python for air traffic control?

[Ralph Corderoy]

Hi,

> 1. No program EVER has 100% coverage during testing (unless it is
> trivial - this for the nitpickers :-)). The bigger the program the
> less likely full coverage has been achieved, ATC's are big programs.
> Anyone who claims they have 100% tested an ATC are either fools or
> liars - "every line and every circumstance" are NOT POSSIBLE, if you
> think they are then I don't have anything more to say other than get
> a few more years real world experience :-). So, if you plan to 100%
> test a python ATC "each line and every circumstance" then my original
> confidence that it would never be put into production holds (that's
> one of the reason languages have exception handlers - to catch the
> error that the programmer didn't foresee) :-).

I've worked on an ATC program, in particular on the user interface
side.  The software ran on many Unix systems, one per controller.  It
was a mixture of Ada, C, and assembler.  Dynamic memory allocation was
widely used.  The X Window System with Motif and PEX libraries was also
utilised along with COTS products like TeleUSE.  There were kernel
extensions for network protocols, etc.

First off, although the lawyers will clear the use of a buggy COTS
product that has a company behind it they won't like the idea of a
`free' piece of software, even one that's much more mature and bug
free.  I've been there.  Perl, Flex, Bison, binutils, and lzop were
just some of the tools used to analyse run-time data offline to prove
correctness.  In the online software the gzip algorithm code was used
(as IIRC its licence allows).  It was just plonked straight in.
However, the lawyers had a issue with that so one of the COTS suppliers
were asked to `supply' it to us.  Problem solved.

As you can see, they're political/law issues rather than technical
suitability.  And they can be solved.  I imagine it's easier now than
it was then given the publicity Free Software has achieved.

As far as coverage testing goes you're right.  They never get near
complete coverage.  In fact, often it is very poor indeed with the
coverage test writers working from the source code they are trying to
cover rather than a spec of the routine.  After much complaining about
this, often the routine was obviously wrong from straightforward
reading of the code, I placed an Easter Egg in one part of the GUI.  If
certain conditions were met then an image of a plane, noise first in
the ground, with smoke rising from its tail together with a man
drifting down from a parachute appeared.  Who says I don't have a GSOH
:-)

Despite the code that included the logic to make the image appear,
together with the image, passing through peer code reviews, coverage
testing, unit testing, integration, you name it, including others
editing that area of the code, it was never discovered.  Shortly before
leaving the project, when it had been on-site, but not in a live
system, for over a year, I announced its existence and removed it.

The major problems, based on this experience, are many.  None specific
to ATC projects but just large software projects involving many
companies with poor staff retainment/training.  There are engineers
that, as I think you said, should have been bakers, engineers who
didn't know C, Unix, Ada, Motif, etc., coding on the project,
management who only plan to be in their position for around 6 months
and so don't care about doing it right but just doing it within
schedule because then it's someone else's problem, and several
sub-contracting companies where none of the parties want to be the
first to announce a schedule slip.  Hell, nothing seems to have changed
since Fred Brooks wrote _The Mythical Man Month_.  A book which few of
my peers or managers had heard of.

So Python in an ATC project?  Sure, don't see why not.  With the right
libraries it's almost like a domain-specific language.  You'll just
need to educate others.

Hope this helps,


Ralph.