Computerising Air Traffic
Latest in a long line
of calamities is the new UK Air Traffic Control system.
The Company I worked
for used to build Air Traffic Control Systems.
We helped design and
build a system called "MADAP" and one called "KARLDAP".
These names are made
up from the initials of what the systems represent.
The latter I think was
something to do with Karlsruhe Data Acquisition and Processing
and the former something to do with "Middle Airspace".
Basically there are
lots of high power radar systems tracking aircraft and displaying
the results on large circular radar screens. Computers plot where
they predict the aircraft to be going and correct this using
actual radar echoes.
The targets on the screens
carry little labels and a secondary radar system developed from
the military IFF systems (friend or foe identification) produces
an automatic response from the aircraft which is used to help
identify the radar echo.
In my experience the
hardware for these things (computers, consoles and displays etc)
is usually not a problem and many people that know better probably
think that that represents the bulk of what will be delivered
at the end of the day. Unfortunately it's not..
...the largest part
is undoubtedly the software element.
As this part is merely
a collection of "zeroes" and "ones" cleverly
put together to make the computers do a lot of jobs, which would
take ages using pencil and paper, and as the entire software
package could be written on a device so small it could be lost
in one's pocket, the importance of it can easily be understated.
The management of hardware
is well understood and difficulties, usually quite easily interpreted,
can be discussed by anyone with half a brain.
The management of software
production is not straightforward and in my experience software
problems are often brushed aside to be "cleared up later"
in an ever decreasing amount of time.
If a software problem
is solved it's generally in a micro-way rather than a macro-way.
That is the observed
problem is usually cured but two others will appear later because
the solution upset a grander scheme perhaps devised by two programmers
months before in their coffee break and never properly documented.
"Management"
often sees programming as a relatively simple task and from the
outset will employ a team of unsuitable people to undertake the
job when really programming requires very special skills and
its management requires even more so.
When one major Defence
contractor, with whom I had more than a nodding acquaintance,
was short of programmers it scoured its workforce for people
that were underemployed.
Next a simple test proposed
by "Personnel" to decide whether the people had the
right skills to be a "programmer".
After that, many new
"programmers" were released into the various complex
projects.
Previously the Company
had employed two sorts of people...
those that had grown
up with the Company from the days when this type of employment
had excused them from National Service and who had been selected,
after many years of toil in a defence contract, because of a
true strength in programming and secondly, University Graduates.
A long time ago the
latter were a rare breed because Universities were few and entrance
qualifications high, a programmer might be hired from the ranks
of virtually any discipline and it was not uncommon to have ancient
greek scholars (not ancient Greeks per se) rubbing shoulders
with mathematicians in a team of radar processing analysts.
Firms were relatively
safe in employing a graduate, as in getting their degree they
had already shown a measure of intelligence.
It remained for the
interviewers to pick from those applying, those they thought
had aptitude and who would be best for the job.
Twenty years later,
with an avalanche of major defence contracts coupled with huge
requirements for programmers in non-defence jobs such as banking
and manufacturing, programmers were in short supply.
So it was in the Company
in question that retrained storemen, production staff and labourers
were absorbed into a particular complex software project.
That project, after
the expenditure of countless millions, eventually became the
subject of "clause SC43". It was cancelled by MoD because
of insurmountable software problems!
A national shortage
of skilled people was also solved by the Government.
Universities suddenly
found themselves competing with ex-technical colleges, ex-business
colleges and a plethora of new institutions.
What became of the top
few percent of A level students?
With a government inspired
push for opening further education to all, now most A-level students
aspired to further education and new "Universities"
abounded.
Now you must understand
that examination results are based, not altogether on performance,
but essentially an adherence to a statistical process which may
be called something like a "gaussian distribution".
An examining body will
set out a curve which pre-determines the result of an examination
before any student has set pen to paper!
This may dictate for
example that 10% of students will get an "A", 20% will
get "B" and so on.
This now applies not
just to University examinations, where 10% will get a "first
class honours degree" etc. but right down to the lowest
level of our education service.
Neat eh?
Nationally our "standards"
can never fall!
Locally they can because
it is pretty obvious to anyone that looks at the end results
that it is wrong for someone to get a GCSE "A" for
English if he can't read or write.
To avoid this there
is a complicated process which overlays yet another statistical
test across individual schools.
The result is a league
table, again no doubt pre-determined by yet another statistical
distribution.
Anyway the problem which
now presents itself to employers is to winkle out those applicants
suitable for programming complex software projects.
What if there aren't
any?
Lower your standards
and select the best available.
With competition rife,
probably what would have been the most useful people will now
have been attracted to City Institutions offering the best salaries.
Anyone that worked as
a "real-time" system programmer will know that sometimes
the pressures are intense.
Not everyone will put
up with this and will pack up and go and work for a bank.
Because of this a High
Tech Company is forced to look outside its own organisation and
hire "Contract staff".
These are people who
command mammoth salaries, commute long distances in their Lotus
sports cars and usually have the skills needed to put an ailing
project back in business.
On the other hand if
they don't like the job they'll pack up and go somewhere else.
Often they are the same
breed of people that used to be employed years ago but left when
they saw the state of things now, to get quadruple salaries working
on their own account, leaving behind the less able people to
bumble along and put things like new Air Traffic Control systems
in the mire.
Following the statement
by the Government and the Airlines yesterday (March 27th 2001)
about how they intend to fix the new ATC system; nothing to do
with putting right the software but "Appointing a Project
Manager". I await the outcome with interest but I don't
think I'll be flying anywhere just in case some of those zeroes
and ones got transposed!
Well... since penning
this the system has been accepted and put on-line; there's been
two major system crashes with thousands of flights backed up
and tens of thousands of passengers hanging around waiting for
things to be sorted out.
When I worked on my
last major project involving software the boss agreed with the
customer some weazel words that effectively said the system was
going to go wrong but if this would be only a small chance then
it'd be OK to accept it and put it into service. There then followed
a trial. Over 1000 system crashes occurred. These were carefully
analysed and some sorted out. Most were easy to fix, being obvious
shortcomings in programming; due to finger trouble and typo's.
Code was put right and a further trial run. Crashes were much
fewer. Most were put right and the system was by then deemed
to be acceptable. The trouble was that the remaining faults were
getting pretty obscure and difficult to fix.
So it seems with air
traffic control. The latent faults still remaining are the most
difficult to fix.
Eventually, what is
now on obsolete system in terms of hardware, will be replaced
with a new one and software faults will again rear their heads.
Next time it will be a different supplier and a different customer,
and no-one will remember what went on previously.
Strange as it may seem,
one of the problems with the newest British System is that the
labels next to the radar targets are too small for the operators
to read them. What's the point of accepting a system costing
millions and millions of pounds whose final output is labels
against radar targets when you can't actually read them! Did
no-one think to mention this when the acceptance tests were run?
Presumably nobody bothered to check to see if a real Air Traffic
Controller was happy with the final outcome? Never mind the quality..
feel the width!
