Total Operations Processing System (TOPS) is a computer system for managing railway locomotives and rolling stock, known for many years of use in the United Kingdom.
TOPS was originally developed between the Southern Pacific Railroad (SP), Stanford University and IBM as a replacement for paper-based systems for managing rail logistics. A jointly-owned consultancy company, TOPS On-Line Inc., was established in 1960 with the goal of implementing TOPS, as well as selling it to third parties. Development was protracted, requiring around 660 man-years of effort to produce a releasable build. During mid-1968, the first phase of the system was introduced on the SP, and quickly proved its advantages over the traditional methods practiced prior to its availability.[1]
In addition to SP, TOPS was widely adopted throughout North America and beyond. While it was at one point in widespread use across many of the United States railroads, the system has been perhaps most prominently used in the United Kingdom. During 1971, the country's nationalised rail operation, British Rail (BR), opted to procure and integrate TOPS into its operations. The acquisition of an existing system rather than develop an indigenous programme was reasoned to be both cheaper and quicker to implement; it was noted, however, that TOPS was not capable of performing all desired functions. Since its implementation during the mid 1970s, both BR and its successors have continued to operate the system. SP itself has developed a newer system called the Terminal Information Processing System (TIPS), which replaced TOPS entirely during 1980.[1]
Early development
During the 1950s and 1960s, it was increasingly recognised that the adoption of computer-based management systems could provide substantial benefits in various operations, particularly those involving logistics.[2] Consequently, by the 1960s, various railways in various countries, including Japan, Canada, and the United States had begun to develop and introduce such systems. Amongst the organisations that adopted the technology early on was the Southern Pacific Railroad (SP).[2]
During the late 1950s, SP entered into discussions with the American technology company IBM about implementing its technology for rail management purposes.[2] IBM repurposed much of their work on the US Air Force's SAGE project, designed to direct interceptor aircraft against approaching Soviet nuclear bombers, to instead serve the needs of the Southern Pacific.[3] The project gained the name Total Operations Processing System, or TOPS, and its development was handled by a specially established consultancy company, TOPS On-Line Inc., which was 80 percent owned by SP with the remaining stake held by IBM.[2]
TOPS was to take all the paperwork associated with a locomotive or rolling stock - its maintenance history, its allocation to division and depot and duty, its status, its location, and much more - and keep it in computer form, constantly updated by terminals at every maintenance facility.[4][2] On paper, this information was difficult to keep track of, awkward to keep up to date, and time-consuming to query, requiring many telephone calls. Computerizing this information enabled a railroad to keep better track of its assets, and thus to make better use of them.[4]
TOPS was a relatively complex system for the era, being not only comprehensive but required to operate in real time.[2] Accordingly, development was particularly time-consuming; according to BR Chief Operations Manager Robert Amott, the first phase of TOPS involved around 660 man-years of effort, with eight years passing between the start of work and it being declared operational during mid-1968. Despite the lengthy development time, TOPS quickly proved to be a success for SP; clerks often observed that jobs which had taken half a day and dozens of telephone calls could instead be completed in under five minutes using TOPS.[2]
The success of TOPS with SP soon led to a quick succession of sales of the system to a variety of other American railroads, along with international customers, where it typically proved to be similarly beneficial.[2] Selling TOPS to other operators helped offset the systems' development costs, so SP was keen to sell TOPS to third parties. The company was also motivated to protect its reputation, and thus provided assistance to other railroads interested in TOPS, to improve its chances of success.[2] Some operators, such as the Canadian National Railway, opted to introduce TOPS as an interim measure while its own bespoke system was developed as a long-term successor.[2]
Adoption by British Rail
During late 1960s, British Rail (BR) was looking for ways to increase efficiency, particularly of its declining freight operations, and identified a computer-based system as a key tool for improving both planning and control.[2] The specific requirements included the more effective utilisation of freight rolling stock, better pre-planning of terminal and marshalling yard operations, better alignment of specific consignments to specific services, prompt response to customer location-related requests. BR planners realised early on that it would be quicker and cheaper to buy an existing system, rather than develop one locally, even if that breached the British Government's requirement for nationalised industries to 'Buy British'.
Various systems around the world were explored, such as France's Gestion Centralisée du Trafic Marchandises (GCTM) and Canada's Traffic Reporting and Control System (TRACS), but found this to be ill-suited to BR's requirements; in fact, no existing system in the world satisfied them in full.[2] However, SP's TOPS system was one such system explored, during which it was determined that it met many of the outstanding requirements, albeit not all. Starting in June 1970, several delegations from SP came to the UK to discuss and evaluate BR's existing practices, along with corresponding visits to the US to witness SP's operations, before both sides concluded that TOPS was a viable option.[2]
Groundwork on TOPS' financial case had commenced in the summer of 1970, during which a four-year timescale for implementation had emerged as the preferred option.[2] From an analysis performed in 1971, it was found that, even in the event of the most pessimistic assumptions bearing true, TOPS' introduction retained a healthy gain in net value of £34m per annum. Suitably convinced of its benefits, BR's board opted to purchase the system, along with the source code (as was typical in those days for such a large mainframe-based system) during June 1971.[2] Due to its foreign origins, the purchase of an IBM System/360 mainframe to operate TOPS had to be approved by the Heath cabinet, which was given in October 1971. The decision was justified by a belief that TOPS would enable BR's freight operations to become profitable.[2]
The cost of BR's TOPS implementation included £5.6m of capital costs, development costs of £5.7m, and equipment rental costs of £22.5m between 1972 and 1980.[2] Aside from the computers themselves, and suitably trained staff to operate them, perhaps the most technically challenging aspect impacting implementation was telecommunications, necessary to bring the system's geographically disparate elements together.[2] The implementation phase was greatly assisted by data processing experts provided by SP. It was at the urging of SP's specialists that BR omitted the originally-sought volume acceptance feature, as it was considered to be impractical.[2]
The operational headquarters for TOPS was established in an existing railway office block in close proximity to BR's corporate headquarters.[2] The building had to be extensively refitted for the scheme, the top floor being turned into an open-plan office for housing planning and development work, while the computing equipment and telecommunications gear was accommodated across two separate floors below; the latter required a controlled climate to avoid adversely impacting the equipment's reliability. According to Amott, the implementation of TOPS was undertaken without any significant adverse reaction in terms of industrial relations or senior management.[2]
The adoption of the TOPS system during the early 1970s led to several changes in working practices across Britain's railway network. Hitherto, locomotives had been numbered in three different series. Steam locomotives carried unadorned numbers up to five digits long. Diesel locomotives carried one to four-digit numbers prefixed with a letter 'D', and electric locomotives with a letter 'E'. Thus, up to three locomotives could carry the same number. TOPS could not handle that, and it also required similar locomotives to be numbered in a consecutive series in terms of classification, so that they might be treated as a group.
Brush Type 2 locomotives became Class 31 under TOPS. This is the data panel from a Class 31/4; the 31/4 subclass being used for locomotives with Electric Train Heating.
Sequentiality was all that was required but, given the need to renumber, it was decided to adopt a logical system for classification, and the five- or six-digit TOPS number was divided into two parts. No class of locomotive or multiple unit numbered over 1,000 examples, so the last three digits were used for the individual number between 001 and 999 in that class, although Class 43 goes down to 000, that being the number of the only remaining HST prototype power car. The first two or three digits were used to denote the class of locomotive or multiple unit. The numbers were often written in two space separated groups, such as "47 401" to highlight that division, but the TOPS system actually stored and displayed them without the space: "47401". Sub-classifications were indicated in the TOPS system with a slash and a subclass number, e.g. "47/4". It was convention, though not enforced within the TOPS system, that subclass numbers were boundaries in the locomotive numbering system, such that class "47/4" started with number "47 401". If there were more than 99 numbers in a subclass, the number series extended to the next value of the third digit; thus, since there were more than 200 locomotives in class "47/4", subclasses "47/5" and "47/6" did not exist, and the next valid subclass by convention was "47/7" starting with "47 701". However, in some cases, the sequences do not match, e.g. 158/0 numbers start at 158 701.
Locomotives are assigned classes 01–98: diesel locomotives 01–79 (originally 01–69), AC electric locomotives 80–96, departmental locos (those not in revenue-earning use) 97, and steam locomotives 98. DC electric locomotives were originally allocated classes 70–79 but this was modified in 2011 (see British Rail locomotive and multiple unit numbering and classification); the sole relic of this is Class 73 which continues unrenumbered, probably because it can be considered equally a diesel locomotive as it is a DC electric. One oddity was the inclusion of British Rail's shipping fleet in the system as Class 99. Diesel multiple units (DMUs) with mechanical or hydraulic transmission are classified 100–199, with electric transmission 200–299. Electric multiple units (EMUs) are given the subsequent classes; 300–399 are overhead AC units (including AC/DC dual-voltage units), while Southern Region DC third rail EMUs are 400–499, other DC EMUs 500–599. More recently, new electric multiple units and bi-mode multiple units have been given the 700 series and new high-speed units have been given the 800 series. Selected numbers in the 900 series have been used for departmental multiple units, mostly converted from former passenger units.
Coaching stock and individual multiple unit cars are allocated five-digit numbers; since the early 1980s, it has been forbidden for them to have the same numbers as locomotives, but before then duplication was possible because they carried a prefix letter, which was considered part of the number. More recent EMU deliveries have six-figure coach numbers.
Recent history
TOPS has become outdated in recent decades[when?]. It is a text-terminal, mainframe-driven system; which is regarded as not very user-friendly, and hard to use compared with contemporary computer user-interfaces. In addition, it is written in its own programming language, TOPSTRAN (not strictly speaking a separate language but a set of IBM Assembler macros), and it is increasingly hard to find and train developers to maintain it. The division of British Rail and privatisation has also hurt TOPS, because it was not designed for that purpose; some freight operating companies do not keep information as up to date as they should.[citation needed]
Attempts have been made to 'skin' the system with a more user-friendly interface, called TOPS 2000; in addition, there are other parallel systems now, such as TRUST, Genius and the Mobile Consisting Application (since 2019 marketed as part of the 3Squared RailSmart software suite),[5] but none has yet fully supplanted the TOPS system.
Sample output
This is a typical report that a TOPS clerk could generate. The train in question is a 25 wagon freight train travelling from Over & Wharton, near Winsford, to Reading West Junction, Berkshire.[6]
K383400 0010 2837 22/10/86 U483 ON N199 BY KO
TRAIN ENQUIRY RESPONSE FOR 377Z380 22 TFA - 9KJ
ACTUAL TRAIN ID 377Z380 22 BOOKED 7Z380
DEP OVER&WHAR 1520 22 2 HRS 20 MINS LATE FOR REASON L CAT B SECTOR 5
LOCO 25901
LOCO 25908
25 LDS 0 MTYS 886 TONNES 799 T/FT 418 POTENTIAL VAC BRAKE FORCE
STATION CONSIST ARR DEP LDS MTYS SCHEDULE
37015 OVER&WHAR 1520 025 000 71212
65700 BESCOTYD NRP 1707 EST 1709 EST 025 000
74260 READINGWJ DETAIL 2007 EST 025 000
END
^Aylen, Jonathan; Gwynne, Bob (1 March 2019). "Meet Tops British Rail's Management System". ITNOW. 61 (1): 46–47. doi:10.1093/itnow/bwz019.
^ abSimmons, Jack; Biddle, Gordon (1997). The Oxford Companion to British Railway History From 1603 to the 1990s (1st ed.). Oxford: Oxford University Press. ISBN0-19-211697-5., pp. 515-516.
