True Story No30

 

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!

Return to home page