Sutherland

Home

Background, culled from Wikipedia

The Real Time Club is London's oldest technology dining society, having celebrated its 40th anniversary in June 2007. The club styles itself as a "Dining Society with Attitude"; dinners are followed by a speaker with deep knowledge of a subject, but whose position on it may be challenged directly by other diners. Meetings are held under the Chatham House Rules so that frank responses are encouraged.  Although for the first 25 years of its existence the RTC dined at numerous London restaurants, dinners are now usually at the National Liberal Club in Whitehall. The club has a long history of political lobbying both through direct interaction with decision makers and producing reports.

I am here under false pretences, as an engineer turned businessman, and also at very short notice, and I hope therefore you will excuse me if I speak from notes - what is known as a well-scripted impromptu talk. I understand that this gathering has a fair preponderance of software house representation and apart from that piece of information the only instructions I have about "singing for my supper" are to talk, in an off-the­-record environment, for a few minutes, and to be as provocative as I like and to expect the fish to rise to the “bait”. This gives me a fair degree of latitude in the choice of a subject - I wondered, perhaps, whether "life with Weinstock" might have been a good - and indeed a topical - subject, but I'm sure that would have had me in the Sunday papers in no time, to say nothing of losing my job! The little note that came round billed me as talking on air traffic control but, quite frankly, I would like to widen that quite a bit, and with the benefit of a captive audience to "have a go" (perhaps a little in fun) at one or two of my favourite hobby horses. If, in "having a go" it helps us to understand one another better, then it will be certainly worthwhile, and I am sure that some of you will "have a go" at me in return.

To set the scene very briefly, my markets in Marconi Radar Systems Limited cover air defence, air traffic control, naval weapon systems and control and instrumentation for military, naval and ATC purposes. Post-merger, my company was made up of the radar and associated interests of BTH and Metrovick, Elliott and Marconi. I now have some 4500 to 5000 people and annual sales of about £30 million. This is a high-technology business and my annual spend on R&D is about £5 million, broadly half out of revenue, and half through Government sponsorship on Research and Development contracts.

My turnover consists of roughly 55-60% export, averaged over a period of years, although it is budgeted at 70% in the current year, and I could go on at length about the relationship "between Government and export business and Government support in our overseas selling”, but that is more appropriate to another occasion and another forum.

I personally have been in the radar business since 1941 and although I'm not very clever, like all you chaps, neither am I very inexperienced! I'm more of an old-timer than a real-timer, but am relieved to see that I am not alone in that respect!

Since this is the Real Time Club, when I was preparing a few things to say, I started out to analyse what proportion of my business could be said to be "real time data processing" and gave up very quickly on grounds of definition! Virtually every aspect of our activity these days has a high content of digital technology, closely akin to "data processing" in the true sense. Therefore, although we have carried out nearly forty major specific data handling systems in these fields in the last decade, there is also a data handling content to nearly all our work. In the extraction of data from radar signals, the driving of displays, the suppression of unwanted radar echoes, the decoding of secondary radar signals - to take four examples almost at random - we are doing just as much a real-time data processing task as one would do in, for example, searching for conflict in an air traffic control system. Therefore, to introduce some of my ideas, it may be worth mentioning how the Marconi Company came to be in real-time data processing at all.

Casting my mind "back, I think three almost simultaneous events in the mid-fifties were significant in our entry to the data handling field - firstly, the decision to offer to Sweden, who needed a number of new sector operations centres, a digital solution which involved us in starting from scratch in computer design. This was the first computer controlled air defence system in Europe, was contemporary with SAGE, well before LINESMAN, and as such represented a big technological and commercial gamble which I am pleased to say we won. The second event was our work in 1957-58 for HMG on a very large defence system for the accurate location of large numbers of jamming targets. The development consisted of the design of a number of elements, each of which had processing requirements which we were meeting by special purpose devices - virtually on one day we did what we call to this day "our agonising re-appraisal" and solved all the problems by a programmable central processor. And thirdly, and fortuitously, a group of development engineers who were pursuing, again in the mid to late fifties, the design of standard digital logical elements, decided to test them by putting them together in - a computer - no less. Soon after the first venture into computer design and manufacture, we recognised the obvious need to take a thoroughly professional view of the programming activity and set up a programming department, called CASD, about twelve years ago. So long ago that I've even forgotten what the initials stand for. [Editors note - Central Automation Systems Department] Nevertheless, this department formed the nucleus of our present software enterprise.

What I am getting at is that this evolution of computer technology from within a radar engineering group, with the subsequent development of the Myriad range and the emergence of systems analysis and operational application from within the heart of the radar business, has given us a very independent (and some might even say arrogant) attitude towards the professional software houses. I hope that by explaining the background to this view you may understand us a little better. When our customer says he will go to a software house for systems advice, you must at least realise our feelings, even if you don't excuse or accept them. We feel most strongly that in our field the outside software house can do no more (and frequently less) than our own team which goes right through from systems engineers and analysts and all grades of programmers, backed by substantial libraries of programmes and routines etc., (forgive me, if I am not very good at the “jargon”) and an extremely powerful bureau. Indeed, we have a "software house" more substantial than most independent houses within the radar organisation, in the same way that we have a marketing organisation, design offices, technical support, project organisations etc. We find, as a very sweeping generalisation, the closer the association of both the people and the work with the hardware of the system, the more effective the results of the application programming activity. It is equally important to recognise the pitfalls of great knowledge and experience of operational application and its associated programme writing, without the real ability to organise total software packages in the general sense - in other words the particular is no good without the general, but equally the general is lost without the particular.

In addition to the general software and application teams, and our powerful real-time bureau, we have available the resources of a large mathematical sciences team, with substantial scientific computing capacity, within the Research Labs of GEC-Marconi at Great Baddow. Therefore on the consultancy and study side we feel we can offer the customer a fuller and yet more specialised service. To be really provocative, if you need a second opinion for a pain in the foot, you expect to see a foot specialist, not someone who had been taking out an appendix on Monday, testing eyes on Tuesday, filling teeth on Wednesday and delivering a baby on Thursday. In other words, experience in business systems, hospital store keeping, airline reservations, seaport layouts etc., can only have marginal relevance in the operational aspects of air defence, naval weapons or air traffic control; although such varied experience may have value in the central organisation of a software system, but is no substitute for true operational experience. Having said all that, we do, of course, regularly need help and advice on specific topics from outside software houses for which we are most grateful and we clearly have peaks in total software effort which it is not always appropriate to fill on a permanent basis, in which help from software houses can be vital.

Changing the subject slightly, I think we have all got to recognise that a few years ago it was a world-wide "fact of life" that in major projects, the cost, time-scale and storage requirements of the programming content would escalate, sometimes grossly.

It may, perhaps be worthwhile examining some of the reasons why in many of our overseas projects we have been successful in time-scale and. costs, and why in British Government work, time-scale , costs, and indeed the whole projects sometime appear to have got out of control. First and foremost it is vital for the customer to define exactly what his objectives are, to discuss them fully with the contractor - to fund sufficient study work to enable these objectives to be set down in a clearly useable and practical form. Secondly during the progress of the task (more particularly in business where the definition is fluffy at the outset) there must be a single authoritative and decisive body, or preferably individual, who will give quick and sensible responses to queries and difficulties, be they technical, operational or contractual.

A shining example of this is the Swedish Air Force Board (now Air Materiel Command) who procured the computer controlled air defence scheme I mentioned before. In this case, after discussion and study, they stated their exact requirements and then stood back and let us get on with it, dealing very quickly with problems along the way by reference to a single individual. We started after LINESMAN, completed from start to finish in four and a half years, provided equipment one generation more modern than LINESMAN, and the Swedes have had this equipment fully operational for twelve years, and indeed, in 1971 we handed over extensions and modernisations to the system which put it now at least two generations ahead.

I believe that we have now learned the lessons - that the specifications must be absolutely clear before embarking on the task, and that it is necessary to spend a fair amount of money on a definition stage if the total task is to be estimated sufficiently accurately to offer a fixed price to a customer.

I think we all of us continue to be appalled by the labour market in junior and middle grade programming staff - of all the people I employ, both professional and non-professional - office people and factory people - the programmer is universally the most personally acquisitive and one with least loyalty to his task, his colleagues and his company. There must be more to it than just the market demand - I would be interested in your own views as employers of such effort.

Coming now to the present and the future - air defence, air traffic control and naval systems take a long time to specify and implement - historically, massive delays in programming have added to this long time. Therefore the systems themselves must have a long life in service on the grounds of sheer expense. Thus one gets a prominent air defence system, not 30 miles from here, about to slip quietly into service at the end of this year, and the major naval system currently at sea in the most modern warships — both based on vast central processors, with germanium logic and a speed comparable to a No.11 bus! Incidentally, I have met a number of very well qualified young serving officers in the last year or two who are thoroughly frustrated by the antiques of hardware and software in their charge.

This present, or past concept just cannot be perpetuated - the problems of cabling and interference engendered by vast volumes of data transfer into the centre - the problems of writing almost thousands of man years of programme and the virtually impossible task of commissioning the system, must lead us all to conclude that for the current and future applications we must look to distributed data processing. All the local functions must be performed by small processors actually within the local equipment be it a display position, input/output device or operators' position of some kind. To be really provocative this can be almost an "engineer programmable" device (if you will pardon the expression) or at least have a very simple software structure and can even be a "special purpose" made up of standard-logic elements. The interchange of data between the self-propelled local positions and a central processor only becomes necessary at all in bigger systems, and only then to signify changes in basic data or functions stored centrally, for overall supervision, recognition of operator action or transfer to other positions. Thus, one evolves a system which can do all that the previous ones have done, but does so with a fraction of the programming complexity, with the potential of much greater flexibility for change, up-date or progressively replace the functions and the hardware. One could see this type of system being available much more quickly and much more economically than anything done so far. Indeed, and off the record, my own company is preparing shortly to launch just such a hardware and software capability.

And, finally, although perhaps most of you are primarily concerned with the selling and implementation of software, per se, this is only a part of my company's activity. We are a systems company in the truest sense, and it is frequently our task to start with an outline Operational Requirement and a piece of virgin desert. This then goes through all the stages of converting the OR to an equipment and software specification, designing the special purpose hardware, designing buildings, devising test specifications and manufacture, installation and test, of not only the radar but of power generation, communications, water and fuel supplies, security, domestic accommodation, documentation, handbooks, spares, training etc., followed frequently by the supply of man-power for operation and maintenance, and all the aspects of subsequent system support. That’s about it - so now I propose to throw myself to the wolves!

[Editor’s note: Unfortunately we have no record of the ensuing ‘debate’!]

Sutherland

Home