Posted by d.barclay on 28 April 2023 - 10:00am Photo by Sear Greyson on Unsplash

By Ian Pyle, then in the Theoretical Physics Division of AERE Harwell.

The Cold War was frightening: Atomic bombs had been used to bring the second world war to an end, devastating Hiroshima and Nagasaki in Japan. Then there was the arms race. Before the Treaty on the Non-Proliferation of Nuclear Weapons in 1968, all countries were striving to get their bomb (as parodied by Tom Lehrer: “Who’s next?”). 

Conventional military aircraft were widely used on both sides of the Iron Curtain, and radar systems to detect them were deployed to defend national air space. Britain had built a chain of radar stations during the war that were enhanced during the 1960s with advanced electronics.

Life at Harwell, in contrast, was exciting and optimistic. Atomic energy was being used for peaceful purposes, in power stations and for medical isotopes. We used computers extensively to do the calculations, often using software from America, running on the IBM computers at Aldermaston.

So when Harwell director Walter Marshall discovered that the radar system being built was in trouble with its computers, he saw an opportunity for diversification of our skills. The new radar system was called Linesman/Mediator, referring to the separate military and civilian uses of the radar information. For the military defence of the UK Air Space, a set of special computers had been designed and built, but it was not known how to make them work. 

This was the time of the “software crisis” when many computer projects were struggling, and the first “Software Engineering” conference was called to identify the problems and discuss how they might be solved. The Radar Data Processing System (for Linesman) was such a project, with significant problems of size and sensitivity.

As a military procurement project, the Linesman RDPS was developed and installed by a contractor (Plessey) under the supervision of a Government agency (the Royal Radar Establishment at Malvern). RRE had advised Plessey about the computers and interconnections needed, including the programming language, but little about the software engineering. 

We at Harwell became involved, as a diversification project, inside a separate secure wing in building 328. The project was all classified, and the wing had a single controlled door: all the windows were barred to prevent unauthorised entry. I don’t remember any fire precautions – fortunately, none were ever needed!

Our first problem was to discover what the project was for, and what the specific problems were. Because everything was classified, these were hard to discover. Our principal source was a 5-inch thick document describing what the operators had to do about the radar signals. It was implied that the computers would enable them to communicate with one another. We were to assist Malvern in advising Plessey about the software production.

During the 1960s, other computers challenged IBM’s dominance, particularly the Ferranti Atlas computer (for which Plessey produced the core store modules), using 48-bit words, and small computers using 24-bit words. Plessey continued to develop new computers with these word sizes, all incompatible with each other or anything else. They were the XL4 and XL 6 computers, built and now installed for the RDPS, but with no software.

Malvern had invented a programming language, Coral 66 (based on Algol 60) intended for “real-time” computing, but containing no features to support time-sensitivity. Its main innovations were data structures (tables and absolute addressing for variables) and simpler procedure call mechanisms. Malvern had written a compiler to run on the XL4 for a subset of Coral 66, called Mini-Coral, which was intended to be used for programming the RDPS. It was for sequential programming on a single computer, and intrinsically inadequate for the hardware system that had been installed. 

After a year or so of uncovering the problems (when every stone we turned over revealed more problems underneath), the Royal Air Force (as the intended eventual users) brought in big guns (Air-Vice Marshal Moulton) to review the project. His report (classified - I never saw it) rejected Alan Curtis’s advice to scrap all the existing computers and build a new RDPS from IBM computers, but accepted mine, to use the XL4s but with a coherent software engineering approach. He recognised the weakness of software engineering skills in Plessey and changed Harwell’s relationship from just advising Malvern to working with Plessey in significant leadership roles.

As a result, in the summer of 1971 I, with Bob Taylor from Harwell and David England from Plessey, wrote the Software Standard in the secure wing of building 328. This specified and explained all the programming work to be done to produce the software for the RDPS on the XL4 and XL6 computers. Of course, this was classified - but I still have a copy, and it has now been downgraded to “Official”.

The essence of the approach was to identify the system that had to be produced as a set of components, to join them together and demonstrate that they worked by testing them appropriately. Each component is such a system. Many documents were needed; the standard defined what each had to contain, and how it would be identified. This was document SSJ 000001. I have transcribed a copy of the typescript and put it on the Internet here.

Plessey had set up a Linesman division to write the RDPS Software, in West Drayton, where the computers and operator terminals were located, organised into three departments according to the three categories of software that I had identified: primary (Applications), dealing with radar and external activities; secondary (System Foundation), dealing with computer interactions and continuity of service; tertiary (Program Preparation), dealing with the software development process through monitoring quality and resource usage, to compiling and debugging programs.

The first job was to write the top-level design document. As a result of the detailed study done by the Design Nucleus, I wrote the first draft of SDA 000000 and revised it several times to take account of comments. and published Edition 5 as the basis for detailed work on the components there identified. I still have my copy, originally classified, now downgraded. This articulated the central purpose of the system, specified its components, and explained how it was intended to work by the interactions between these components.

At that stage, application software could be designed but not yet tested. Foundation software had to come first. Having the software structured into presystems with suites, packages and modules, departmental managers were responsible for allocating people to appropriate design groups, taking suites in order, and then packages. 

First of all was the On-Line Operating System, OLOS, suite 31, which scheduled the tasks within each computer, and arranged messages to flow between them. Ian Croall of Harwell was the leader for this. Before OLOS was shown to work, Plessey programmers had been uncertain about the whole idea, having been trained in conventional (sequential) programming. Its success was a psychological turning point in the project.

After OLOS, the other suites of the Basic Foundation were written, and Application modules could then be tested. As well as live radar signals, there was a simulated radar source (intended for operator training), that also assisted the testing of application software. 

I left the project after this (I was worn out), and returned to Harwell with new ideas for research into computer inter-communication, and a strong motivation to teach computing properly - not just sequential programming.

The software for the Linesman RDPS grew and the Presystems were progressively demonstrated. The Management could see and measure progress! Although there always were loose ends to tie up, there was a solid core. When the last Presystem, dealing with height-finding radar, had been demonstrated, a Handover meeting was held in July 1973 to report the residual problems and pass responsibility from Plessey to the Royal Air Force. I was no longer involved, but Alan Curtis was, and he gave me his copy of the document for the meeting, with his notes. This also is no longer classified and is available here. 

I consider the handover to be the indicator of success for the project. What had nearly been a technical disaster had been rescued. The full range of functions initially expected was not achieved, but not because of the software. The folly of designing special one-off computers was exposed, as was the importance of the Foundation software (significantly larger than the Application software) - which became apparent again in the IUKADGE project that later replaced Linesman.

 

For further information get in touch with Ian Pyle at: ian.pyle@cantab.net

ORCID 0000-0003-2156-4561

 

Further resources about the Linesman RDPS:

Pyle, I., 2019. Do Computers Care? Adv Comput Sci. 10.31021/acs.20193119

Pyle, I.C., 2019. Software for the Linesman Radar Data Processing System. The Computer Journal, 62(6), pp.806-819. 10.1093/comjnl/bxy097

Pyle, I., 2018. Software Engineering in a British defence project in 1970. In This Changes Everything–ICT and Climate Change: What Can We Do? 13th IFIP TC 9 International Conference on Human Choice and Computers, HCC13 2018, Held at the 24th IFIP World Computer Congress, WCC 2018, Poznan, Poland, September 19–21, 2018, Proceedings 13 (pp. 16-30). Springer International Publishing. 10.1007/978-3-319-99605-9_2